Huh? I thought you weren't supposed to put dynamic strings in t().
What's the party line on translating module names that appear in the interface? D5 core doesn't do this on the modules page, it seems... it just reads whatever is in the .info files and displays that.
Thanks, -Derek
On 6/19/07, Derek Wright drupal@dwwright.net wrote:
Huh? I thought you weren't supposed to put dynamic strings in t().
What's the party line on translating module names that appear in the interface? D5 core doesn't do this on the modules page, it seems... it just reads whatever is in the .info files and displays that.
I don't know whether there is a party line but it doesn't make sense to translate the module names which appear in the "/admin/build/modules" page. That page is supposed to be used by the site administrator for finding and enabling modules. The names must be unambiguous.
This becomes even worse if a translation of some insignificant module overwrites such a translated string.
On the other hand, sometimes a string same as a module's name appears in a menu, which we would like to translate. The current absence of a t() in the module names which appear in "/admin/build/modules" is a good thing because it allows us to translate a module name everywhere else if we want to.
On Jun 18, 2007, at 7:21 PM, Cog Rusty wrote:
I don't know whether there is a party line but it doesn't make sense to translate the module names which appear in the "/admin/build/modules" page.
That's exactly how I felt, and why I marked http://drupal.org/node/ 152375 "won't fix" in the first place. However, it was re-opened, which is why I wanted to get the opinion of the translation experts over here.
thanks, -derek
p.s. I just reset that issue back to "won't fix" with a pointer to this thread.
Cog Rusty wrote:
On 6/19/07, Derek Wright drupal@dwwright.net wrote:
Huh? I thought you weren't supposed to put dynamic strings in t().
What's the party line on translating module names that appear in the interface? D5 core doesn't do this on the modules page, it seems... it just reads whatever is in the .info files and displays that.
I don't know whether there is a party line but it doesn't make sense to translate the module names which appear in the "/admin/build/modules" page. That page is supposed to be used by the site administrator for finding and enabling modules. The names must be unambiguous.
Everywhere else they are translated, and they are not ambiguous. It was definitely possible before to translate module names even on the module list page.
This becomes even worse if a translation of some insignificant module overwrites such a translated string.
Well, you need to trust the translators. They put code into their plural formulas which will be eval()-ed on all your page views (although there is a syntax check to try to prevent problems there, which might or might not be worked around by an evil guy :), they can translate 'enabled' to 'disabled' and vice versa. A translation "of some insignificant module" can break anything on your site in terms of string changes.
On the other hand, sometimes a string same as a module's name appears in a menu, which we would like to translate. The current absence of a t() in the module names which appear in "/admin/build/modules" is a good thing because it allows us to translate a module name everywhere else if we want to.
Allows us? How does it allow us?
BTW I am not against putting the original module name to a visible place. Module names and module file names are already not in concert, lots of them use abbreviations or expanded names. Like core has translation.module which is named "Content translation". With the multiple directories where modules can reside (and given you don't know the file name for sure) also makes hard to find a module on your own installation for starters, not even reaching to a project page.
To help this situation, we can put a 'title="'. t('Original module name: %name, location: %path', array('%name' => $name, '%path' => $path)) . '"' onto the module list items for example (and let the module names be translated).
Gabor
On 6/19/07, Gabor Hojtsy gabor@hojtsy.hu wrote:
Cog Rusty wrote:
...snip...
On the other hand, sometimes a string same as a module's name appears in a menu, which we would like to translate. The current absence of a t() in the module names which appear in "/admin/build/modules" is a good thing because it allows us to translate a module name everywhere else if we want to.
Allows us? How does it allow us?
I mean you can translate an identical string which appears in a menu, and the module name itself in /admin/build/modules can remain unaffected.
BTW I am not against putting the original module name to a visible place. Module names and module file names are already not in concert, lots of them use abbreviations or expanded names. Like core has translation.module which is named "Content translation". With the multiple directories where modules can reside (and given you don't know the file name for sure) also makes hard to find a module on your own installation for starters, not even reaching to a project page.
To help this situation, we can put a 'title="'. t('Original module name: %name, location: %path', array('%name' => $name, '%path' => $path)) . '"' onto the module list items for example (and let the module names be translated).
This could work. In the meanwhile I posted a reply to the issue (http://drupal.org/node/152375) where I try to visualize this in practice.
Gabor
On Jun 19, 2007, at 3:44 AM, Cog Rusty wrote:
In the meanwhile I posted a reply to the issue (http://drupal.org/node/152375) where I try to visualize this in practice.
Cog and Gabor know this, but FYI to everyone else:
I just moved that issue into the core issue queue and bumped the version to 6.x-dev. If anyone else cares, let's continue the discussion there.
Thanks, -Derek
-
Cog Rusty -
Derek Wright -
Gabor Hojtsy