Conflict with i18nstrings (user defined strings not being translated on some sites / to some languages)

Oh, crap. Always the hassle with translation. Patch to follow.

The default language is handled by Domain Conf. We wrote a special workaround for it a while back in domain_conf_domain_bootstrap_full() but this doesn't seem to be enough.

Moving this to Domain Access since this bug would occur even without Domain Locale.

Yes, and I have a patch for it over in the i18n queue, which is being ignored because I can't express the issue clearly.

#709140: Localize Panels and Views menu titles

Not sure I consider this a DA bug. About to be out of pocket for two days.

Alternatively, the problem may be that we are hard-resetting the 'default' language variable per site. Perhaps we should instead by settings a language context per site.

I don't work with i18n enough to have an opinion here.

Hello,

I was going to create an issue for my problem when I saw this issue who could be related.

All my strings are well translated in all domains. I set a default language for each domain.

The only problem I have is that Taxonomy strings don't show the translated string. Only show the original strings.

fra.xxxx.com is set to french.

with this url, taxonomy strings are not translated.
If i use the url us.xxx.com/fr, strings are well translated in French.

On /admin/build/translate/search page, to translate taxonomy strings in French, I can't use this url: fra.xxxx.com/admin/build/translate/search. I have to switch to a domain set in english in order to have the French translation field.
With the url fra.xxxx.com/admin/build/translate/search, I have English translation field instead.

Maybe I should create another issue?

I've also got this problem with :

Content type First name & Last name
type:[node-type]:title
Built-in interface First name & Last name
/admin/content/node-type/[node-type]/fields

This all suggests that we should not be resetting the _default_ language per domain, but should be doing something else to toggle the language interface.

I am open to suggestions.

Unfortunately, I'm not able to help you on this. I don't have the knowledge with this stuff. I just able to do some php code...

Question is what should it be? ATM pretty much everything in contrib depends on global $language.

I think setting the global $language is correct. But it may be that setting $conf['language_default'] is wrong.

Try this. It will keep the 'default' language the same for all domains, but activate the selected.

I just remove:

$value = $temp;
$conf[$key] = $value;

but all translations are gone, in all entire website.

I don't know what you mean.

In /modules/domain/domain_conf/domain_conf.module

I remove "$value = $temp;" and "$conf[$key] = $value;" as your patch indicated.

But No strings are translated anymore. All strings are in english. My fra.xxx.com set in French display strings in English.

All strings are in english. My fra.xxx.com set in French display strings in English.

That's what I needed. Not sure of the solution, then.

Got bitten by the i18nstrings() bug myself today. I'm wondering if it would help any if we would use Domain Conf to set the default language but use another variable name ($domain_language?) to do so and perform some magic when loading pages.

I am open to suggestion. Thought the above patch might do that.

Hello,

Any leads for this bug?

View More link are not translated too. But Panel More Link is.

Menu items are not translated too.

This is critical for a multilanguage website, it's not serious to have some important strings not translated with a website in production :(

Hope a solution to that problem will be find soon ^^

Not critical. Possibly unfixable. BTW: I think i18nstrings is culpable here, too. Maybe try in that queue?

Still crazy with that thing.

@ nonsie

Should I use your modules? Domain Internationalization & Domain Locale? Do i need them both? Only one? Why?

Same problem here. I have tried with Domain Locale enabled and disabled. In both situations the problem stays. Taxonomies, Block Titles, Menu's all are NOT translated.

I give up with the option default language by domain.

Mainteners should leave a note on the module page to warning people about using this option.

This is actually problem with core itself and i18n if you follow #4.
If you only want to change default language per domain you do not need Domain Locale or Domain i18n.
Only use Domain Locale if you want to change the subset of languages available per domain eg.:
example.com has English, Spanish, French
example2.com has English and French
example3.com has English and Spanish

Domain i18n gives you the ability to translate user supplied texts (stored as variables) per domain and language.
For example if you wish to have separate site name for each language per domain.

I have multiple multilingual sites with different default and enabled languages. The only time I had to write some kitten killing code was when outputting menu items - they would not display in the correct language in a block, so I had to write a hack in my theme layer to deal with it.

OK, thanks for your explanation.

I'm wondering why I'm using i18n... I'm going to think about it.

I always though this module was essential to multi-languages websites.

I need translations of taxonomy terms and menu entries, si I think I have no choice, I need i18n.

Well, if you tell tell us what's failing, or what extra you need, that's what this issue is for.

#27: What's needed is that a site with multiple domains and shared content (menus, block, taxonomy) has support for multilanguage where there are per domain a default language.

The problem is that when having domains installed and set per domain a default language, the menu and block titles are not translated. The taxonomies aren't showed at all and thus not translated.

So I have 3 domains:
example.nl
example.de
example.com

My site has first had a default language of dutch (for example.nl). With domains example.de and example.com added. The default language for example.de is German and for example.com is English. In this case the dutch site works well. But when going to the German or English site, the content is shown correctly translated, the language is also set to German or English. Only the menus, block titles and taxonomy are not translated.

So the issue is that content translation works, but some non-content string translation is not applied? Are these strings translated with i18n?

Can you share some screen shots of the Language configuration settings as well.

Update:

1. Adding to settings.php:

$conf['i18nstrings_translate_langcode_XX'] = TRUE; 

Results in Block Titles to be translated.

2. When setting vocabulary to no translation, the Taxonomy is shown. Otherwise it is not shown. Also tried domain_taxonomy module. But with no luck.

3. Menu translating still NOT working

@agentrickard: which configuration settings are you looking for? And yes translation is done via i18n.

The default Drupal language configuration settings.

What happens when you disable Domain Settings (since you use the same setting for all it is an option)? Do taxonomies now appear translated? How are your vocabularies set up - localize terms, per language terms, language per vocabulary?
Also, are there any changes when you change language negotiation to path + language callback?

I'm happy to have found this thread, it is confirmation that I'm not crazy, at least not insomuch as this particular issue is concerned.

I'm experiencing the same problem. A bilingual site, in French / English, using domain based language negotiation. It works fine with i18n, content, menus, and taxonomy terms get translated perfectly.

And then I see that I can use Domain Access, + Domain Blocks to do things, like display blocks on a domain basis, and that I can also do language negotiation using Domain Locale (a bit of an overlap w i18n here?) ... which looks very promising. I configured the language of the French and English domains appropriates, and now Content appears in appropriate language, but my menus and terms aren't getting translated. Arg.

Its taken me a couple of days of tinkering to locate the problem, but when I disable Domain access modules, the terms and menus get translated once again. H'mm.

My hunch is that its not so much an i18n issue, since translations of translatable vocabularies and menus work in the absence of Domain Access.

I wish I could help myself, but I lack the skills.

But I'm keenly interested to see how things progress.

My recollection is that it is an i18n issue, as that module throws away certain translations when it thinks the default language is being used.

Index: i18nstrings/i18nstrings.module
===================================================================
--- i18nstrings/i18nstrings.module	(revision 223)
+++ i18nstrings/i18nstrings.module	(working copy)
@@ -148,6 +148,11 @@
   if ($update) {
     i18nstrings_update_string($name, $string);
   }
+  // We want to translate everything!
+  $new = i18nstrings_tt($name, $string, $langcode, FALSE);
+  if (!is_array($new)) {
+    return $new;
+  }
   // If language is default, just return
   if (language_default('language') == $langcode) {
     return $string;
@@ -883,4 +888,4 @@
   } else {
     return FALSE;
   }
-}
\ No newline at end of file
+}

See #709140: Localize Panels and Views menu titles.

@agentrickard: This code is no were available, so the patch doesn't work. I also had already i18nviews installed.

I've just seen this issue, which I guess is still happening with Drupal 7, so I'm explaining here what's going on mostly for documentation purposes.

The problem

Internationalization (i18n_string) uses site default language as 'source language' for user defined strings. So by default it never attempts to translate strings to that 'source language'. Domain Access changing that default language from domain to domain obviously clashes with how i18n_string works and though this is in principle 'non fixable', there are some workarounds.

If each of the domains is using different menu items, terms, etc, then you should be ok as long as you don't use any bulk operation that updates these strings (The 'refresh strings' option is one of them, but also bulk updating of menu items, terms...) and you always translate the strings for each domain on that domain.

The workaround

Since i18n_string can use some hidden variables to change this default behavior, we can 'trick' the system to translate strings to all the languages we need as long as we have a single 'source language' for all domains or each domain is using different user defined strings, so we need to:

1. For each domain, set 'i18nstrings_translate_langcode_xx' to TRUE, 'xx' being each of the language codes for which we need the strings to be translated (not the 'source' language). You need to add them manually to your config file, as explained in #30.
2. To translate these user defined strings, use only the domain for which the default language is the 'source language'. Using other domains will cause UI inconsistencies, that may result in some translations being lost.
3. With Drupal 7, this 'source language' is configurable through the UI so it doesn't need to match the 'default language' nor it needs to be the same for all domains, unless you are using the same user defined strings in more than one domain.

The bad news: If you are creating strings (menus, terms, etc) in different source languages, and using the same strings for different domains with different default language, this won't work. Worse, I think it will never work until Drupal core provides some good translation system for user defined strings or we can find the time to completely overhaul i18n_string with a new data model that supports this.

Changing version to 7.x, and status to 'won't fix'. Linking this issue from i18n documentation. Hope it helps.

Fixing status according to the above comment.

I came across this problem and glad I saw this post. Thanks for documenting it...but can someone please advise how to implement the workaround in #30 as pointed out in #38 comment.
"For each domain, set 'i18nstrings_translate_langcode_xx' to TRUE, 'xx' being each of the language codes for which we need the strings to be translated (not the 'source' language). You need to add them manually to your config file, as explained in #30.
".
I need help in understanding on how to set these variable for each domain in settings.php file.

Appreciate the help.