Jump to:
| Project: | Localization client |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
I would know if there is a plan to provide the ability to translate the default english language too.
The language standard for all drupal modules etc... is english, this module is so usefull when you have another language installed and you want to translate it, but, sometime, the "core" language translation don't fill your need.
There is the string override that allow to change the core english language, but it provide a new configuration page etc.... so, when you have i18n, localization client, locale, string override.... it begin to make a lot of confusing administration page for, finally, the same thing...
So is there a plan to update this module to allow to override all string you want (english included) by merging with string override or other... or do we have to deal with so many different administration page to translate your strings ?
thanks
zmove
Comments
#1
The recipe for your issue is to add an "English customized" language and just use that to customize the English interface whenever you want.
#2
Automatically closed -- issue fixed for two weeks with no activity.
#3
I have one of these 'english customized' languages. So the localization client shows up on this (and all other) languages offcourse. Is there a way to 'disable' the localization client for these customized languages?
#4
This solution (creating "customized english") does not seem to really work when one needs to change e.g. content type name.
1) I create new language, e.g. en-US
2) I translate content type name "uggly content type" to "beautiful content type"
Now users who have language as en-US will see e.g. "Create beautifull content type" instead of "Create uggly content type". But in order for all users to actually see this I must..
3) change default language to en-US
..and then what happens is that "uggly content type" will be actually still seen by all users, since translating defualt language is not possible. What am I missing here? There has to be way around this surely?
#5
#6
You can change content type names via the content types editing user interface. No need to create a whole new language just to change those names.
#7
Automatically closed -- issue fixed for 2 weeks with no activity.
#8
Gábor, I am pretty sure "Ugly content type" was an example here.
I am in the same situation, resorted to created a English custom language. The problem is that Drupal starts looking for and creating reference strings in that language, instead of 'en'.
The solution would be to always use the 'en' language as the reference, regardless of what the default is for the user interface, and regardless of what languages are active.
I don't think this would be a very heavy change, and not checking for the current language would actually have a positive impact on performance.
#9
@Gabriel: who guarantees that people will enter English names for stuff. Why should we need to force people to do so, if they set up a site to be accessible in French and Italian only for example?
#10
We are talking source code here, advising people to use english for the reference strings is NOT a bad idea. It will actually help them retrieve translations more easily.
Plus, nothing stops them from entering French and Italian in the source EN language. It will be ugly but will remain logical and not corrupt the PO's.
#11
I think there are too many questions mixed in this issue.
For overriding English strings, check http://drupal.org/project/stringoverrides
(It may be a feature request for it to work with l10n_client)
Custom strings (content type names) are just not translatable with Drupal core, check out Internationalzation module for that (which works with l10n_client too btw).
Hardcoding strings in languages other than English is just bad coding practices, there's nothing we can (or want) to do about it.
So, I'm closing this one, please open proper issues (one question at a time) for the proper modules (mentioned above).