I consider this a bug since:
If you develop a site in english and working on a page that will be presented in multiple languages the tt() functionality might get wrong.
In the final release we disable english as a presentation language and switch default to one of the custom languages. While this language worked perfectly before it is no more working from this very moment since (previously entered) language fields with perfect translations entered stop to translate into the default language.
It's as simple as editing function tt() to always call i18nstrings_tt() @154
So we need an option to enable translation for even the current default language. Disabling this translation cycle is not safe for every case.
Are you willing to add this option?
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | i18nstrings_alternate_translate_default.patch | 805 bytes | jose reyero |
| #13 | i18nstrings_default_translate-676002-13.patch | 4.1 KB | miro_dietiker |
| #12 | i18nstrings_default_translate-676002-12.patch | 3.06 KB | markus_petrux |
| #8 | i18nstrings_default_translate.patch | 4.28 KB | miro_dietiker |
Comments
Comment #1
miro_dietikersorry, title corrections.
Comment #2
pasquallehttp://drupal.org/node/313293
Comment #3
miro_dietikerPasqualle
This issue is about solving the general problem and limitation.
It is strictly very bad design to have internal development and t() in english while having user config text in final site language. The only right solution is to allow internal setup in e.g. english and later on translate to N languages.
Indeed we should separate system internal default language from default presentation language -- but in any cases we should TRANSLATE everything entered in the system into the default presentation language.
As a special case for non-international sites you might inactivate this feature and tell: presentation_default=internal_default=development_default
But you might don't need any i18n this way ;-)
The system would get much more flexible this way. And the myth of a translation nightmare will go away!
I have a clear understanding (of the internal data, states and processes) of what is needed to be able to switch default language on a production site and everything still works. It's just about a few changes and we'll have a new dimension in flexibility.
Comment #4
pasqualleno, it is not a very bad design. Many many websites do not have English content, so it would be wrong to require entering every dynamic text in English first, to be able to translate it..
the interface text source is in English, it can not be changed..
http://api.drupal.org/api/function/t/6
$string A string containing the English string to translate.
http://groups.drupal.org/node/24438
Comment #5
infojunkieJust chiming in with my own experience: I build my sites in English but I wanted one particular site to be displayed in French. So I set the default language to be French after completing the site construction. The i18n stopped translating! For good reason given the discussion above.
So I traced the code and found that the current language, whatever it is, does not get translated. This doesn't feel right, and if the solution is as simple as removing the check for current language, then what can be wrong with that? Would the performance hit be significant? Are there cases where the logic fails?
Comment #6
miro_dietikerinfojunkie you're getting it absolutely right.
Nothing else breaks. We're doing right this on a pretty huge project with many many modules and added complexity without any side effects.
Sure it adds some performance loss for default language. But that's exactly why i've suggested adding a variable to enable translating default language translation. I see no further reason for objections from maintainers.
Improving concepts and correcting things to be more general and removing limitations is by far more than quoting documents that report do's and don't's. Many drupal/contrib documentations need improvement and are even wrong. I've took much time to think about all that and inspected the whole code in i18n, drupal core locale, and many more modules.
Please, i18n maintainers, open your mind and think about it again.
Comment #7
jose reyero commentedJust disabling the language check won't work because it will cause a ton of useless queries.
So give me a patch with some -may be hidden- variable to enable this 'feature'.
Comment #8
miro_dietikerAttached patch is against 6.x-1.x-dev and introduces a variable called "i18nstrings_translate_default".
If you like to enable default text translation you need to edit variables (using devel, drush or SQL) directly.
It also introduces a function to generally check if translation is required for a given langcode.
A local static cache might not necessarily be needed but is added to reduce extensive variable_get and language_default fetches. No performance measurement done but it runs smooth without any side effect.
Added some help text for users to understand what default language and optional translation means. I'm absolutely sure it can be improved by natives... ;-)
Glad to see your inputs.
Comment #9
infojunkieWorks for me. Thanks!
Comment #10
eugenmayer commentedworked for me.
Comment #11
eugenmayer commentedComment #12
markus_petrux commentedPatch re-rolled because patch in #8 does not apply, a few things have changed in regards to tt(), now deprecated. Also, I think I have simplified the implementation a little, and added code comments to document how to enable this feature.
I think this 'feature' is not only necessary, but a must when, for whatever reason, the default site language is changed. Things related to i18n have changed during the life cycle of D6. For example, at first the only way to translate CCK field labels was using t(), function that assumes source is english, but now you can use i18n, and you have a problem if your default language is not english.
Comment #13
miro_dietikerClean rewrite, thanks markus.
And sure you're absolutely right. That's why we took the ball to push this important feature.
Note that we put the comments in the file header by intention (and you've moved them down to the function).
There should be some statement about this situation (changing default language) on the project module documentation front page.
The last lines in the patch miss some correction in indentation.
Corrected formattings and added file header descriptions again. Please review or update em.
Comment #14
markus_petrux commentedOh, I forgot to include the comments in the file header. Your patch looks good to me, and I think it conforms to Jose specs in #7. :)
Let's see if we can get a bit more feedback on this last patch to make sure it works ok. Thanks!
Comment #15
cgalli commentedLiving in a country with multiple languages, the default language issue is a nightmare. One wrong click can destroy a site, not to be repaired.
For testing, I set up a german/english site with changing menu titles. Worked fine.
After changing the default language from german back to english, translation of the menu links no longer happened. In real life my site would have to be rebuilt from scratch then!
After applying the patch and adding the conf[] variable to settings.php, the links are being translated again when the language changes.
Thats magic!
Comment #16
miro_dietikerCommitted to repository in current 6--1, thanks for your support.
I'll add some statements in our blog and our group about this new feature.
So this was fixed in dev leading to presence in next 6.x-1.5. Can't tag that version number.
Edit: Added another commit to extend changelog.
Comment #17
markus_petrux commentedSweet! :-D
Comment #18
jose reyero commentedOk, cool.
Just one thing: We do need unit tests for new features.
Comment #19
jose reyero commentedBtw, #795038: Putting out a new 6.x-1.5 release.
Comment #20
jose reyero commentedThinking again about this features, I think this other option may be more flexible.
This way you can decide whether to translate or not each language. Because otherwise you may end up translating default (that may not be English) but also translating English string.
Please, feedback
Comment #21
miro_dietikerYou're right. This is no higher complexity but much more flexibility.
(although it's not necessarily needed in most cases..)
The code looks fine. However please note that we need to update the documentation and README currently representing the previously suggested _default variable.
Comment #22
jose reyero commentedDone. Committed.
Comment #24
iori57 commentedI've added $conf['i18nstrings_translate_default'] = TRUE; in my settings.php and set Chinese as my default language (instead of english), but it still doesn't get translated?
Is there a more detailed example on how to get this to work? Thanks!
Just want to translate the default language which is chinese in this case..
Update:
Got it to work now after reading i18nstrings.module carefully in the final release, seems that the latest instructions is changed and I need to use the code below instead:
// Enable translation of specific language. Language code is 'zh-hans'
$conf['i18nstrings_translate_langcode_zh-hans'] = TRUE;
In this case zh-hans is Simplified Chinese language code, just use your desired one :)
Just for those who are clueless like me and might find this info useful :)
Works perfectly!! Thanks for the great work people! You guys saved many lives with this function :)
Comment #25
Marko B commentedThis is what i use
$conf['i18n_variables'] = array(
// Site name, slogan, mission, etc..
'site_name',
'site_slogan',
'logo_path',
// 'site_mission',
// 'site_footer',
// 'anonymous',
// Different front page for each language
'site_frontpage',
'theme_settings',
'theme_garland_settings',
// Primary and secondary links
// 'menu_primary_links_source',
// 'menu_secondary_links_source',
// Contact form information
// 'contact_form_information',
);
also use this http://drupal-translation.com/content/setting-front-page-language
as you have to set home page for each language, otherwise it wont be good.