Consistancy in friendly names of CG products

[otopanne]

Hello calguy1000,

This topic is aimed at you, since it is about your modules. I hope you are in no way offended, as it is only meant as a bit of tongue-in-cheek criticism.

I really love your modules, I use them all the time. They are very good additions to the (basic and therefore light) core of CMSMS. I love this in CMSMS. For simple websites you just use the core and if you want more functionality then you get a specific module. Of which a lot, if not most of them are by your hand. You are a busy bee!
The admin parts of the modules all look alike and the template logic is very consistent. It makes it easy to work with the modules. Amongst the modules I use extensively on my website are Calguys Blog Module, CGCalendar, CG Extensions, Calguy's Feed Maker, Calguy's Smart Image Toolkit and Calguys Content Utilities.

One thing that really* bothers me is the (lack of) consistency in the naming of these modules.
There is the abbreviated CG, but also CG with a space after it. There is Calguys and Calguy's.
(* really is a bit strong, it actually is not important at all, but OCD starts itching when I open the Content or Extensions tab)

Would it be possible to change some of the names, so they are more coherent and uniform?

[calguy1000]

Though it is not actually possible to rename the module itself (the item that you download and that is displayed in the module manager). It is quite easy using the module_custom technique to change the string that is displayed in the admin navigation.

[otopanne]

I understand it is not possible for an end-user to change the names of modules in the Forge or the module manager. I was kind of hoping that you would agree that it might look more uniform and therefore more professional, if the names (of actually prefixes) in the admin navigation were alike.

Anyway, thanks for pointing me to the module_custom technique. I have tried to make this work, but am struggling a bit. When you say 'change the string', you mean to change the value in the lang file for that string, right?

I have used the module_custom technique in the past to change the 'add an event'-template for cgcalendar from a post I found years ago on this forum. It worked by copying the folder structure and the template file to a module_custom folder.

After some searching, I have found some posts on this forum that explain this technique in regards to lang files: here, here and here

If I understand correct, you should create a new file in:
module_custom/CGSmartImage/lang/ext/
Name that file like the locale used for the language and copy the strings you'd want customized to that file. In this case the $lang['friendlyname'] string.

I have changed that to 'CG Smart Image' and cleared cache, yet it is still reading 'Calguy's Smart Image Toolkit' in my admin navigation.
What am I doing wrong?

[Jo Morg]

I was kind of hoping that you would agree that it might look more uniform and therefore more professional, if the names (of actually prefixes) in the admin navigation were alike.

Even if a module developer would agree on that, the process of changing the modules names (note we are not talking about the friendly names) has too many implications in terms of upgrades to be reasonable or practicle to do so...

If I understand correct, you should create a new file in:
module_custom/CGSmartImage/lang/ext/

Nope...
http://docs1.cmsmadesimple.org/customiz ... ge-strings
In this case: module_custom/CGSmartImage/lang/.
With regard to custom lang strings in the module_custom context there is no reason to use the ext sub-dir...

[otopanne]

(note we are not talking about the friendly names)

Sorry for the confusion, but this whole time I've been meaning to say friendly names. I did not know it was called that way until I opened the lang file yesterday.
It did not cross my mind that the friendly names are being translated (probably by different people). The original English friendly names already have the same prefix...

Nope...
http://docs1.cmsmadesimple.org/customiz ... ge-strings
In this case: module_custom/CGSmartImage/lang/.
With regard to custom lang strings in the module_custom context there is no reason to use the ext sub-dir...

Ok, I've managed to get it to work now! Thank you very much!
It was indeed the redundant 'ext' folder that was keeping the customized string from showing up.

As for my initial request to Calguy make the friendly names more consistent, it turns out it's actually the translations that do not use the same format (sorry Calguy )
Perhaps some guidelines could be introduced to make the prefixes more consistent in the translations.