The website I want to discuss has the following configuration (Drupal version 7.12):
domain.be/nl-BE/ => Belgian website, Dutch language
domain.be/fr-BE/ => Belgian website, French language
domain.fr => French website (always French)
domain.nl => Dutch website (always Dutch)
So, there are 4 languages (Belgian NL, Belgian FR, French FR, Dutch NL). The Belgian websites have a language prefix (nl-BE, fr-BE) and there are three different language domains (domain.be, domain.fr and domain.nl). All those settings are configured in Languages (admin/config/regional/language).
There are some taxonomy vocabularies available for some content types. The module 'Taxonomy translation' is enabled so we can localize all the terms. But there is one vocabulary that can't be localized because not all terms on the Belgian domain should appear on the French domain. That's why the option 'Translate. Different terms will be allowed for each language and they can be translated' is enabled.
With this setup we encounter the following problem:
If the editor wants to create a French node in a French environment (domain.fr), there are no problems, because the editor will select the correct (French) term in the French environment. But if the editor wants to create a French node in a Dutch environment (domain.be), he can still choose a French term but after submitting, he gets an error saying that there was an illegal choice.
The only thing the editor can do, at this moment, is continuously switch between the domains (And then there is the natural consequence that the editor needs to log in each time he switches domain), also when the editor wants to translate a certain node. So, all this is very negative for the workflow of an editor.
Is all of this standard Drupal behavior? Has anyone encountered the same problem, and how did you deal with it, or are there practical solutions provided for this specific problem?
Comments
@kafitz, is your site D6 or
@kafitz, is your site D6 or 7?
We had similar problems with this on one of our multi-lingual, multi domain (using the Domain suite of modules for the subdomains) installations in Drupal 6. The behavior from what we could tell was intended in that a user was able to see all taxonomy terms dependent upon both the active language as well as the settings for the specific vocabulary as defined by your configuration on the vocabulary edit screen (i18n provides the config). Here are the options I see:
-None. No multilingual options for this vocabulary.
-Localize terms. Terms are common for all languages, but their name and description may be localized.
-Per language terms. Different terms will be allowed for each language and they can be translated.
-Set language to vocabulary. The vocabulary will have a global language and it will only show up for pages in that language.
My guess is that you have the "localize Terms" option set and therefor it would be possible for a user on the Dutch site to select a french term since they are not being filtered by language. So checking that setting in your vocabulary is a good place to start. MAke sure you have a back up/dev site to test this on before making changes as sometimes language updates will effect tables in ways you were not expecting.
Exact error?
Kristen
Contact: https://www.hook42.com/contact
Drupal 7 Multilingual Sites: http://www.kristen.org/book
More info
Thx Stevenator & Kirsten for the quick response. Here is some more information about the topic.
The website is a Drupal7 installation (7.12). The options that are provided for vocabularies are the following:
All my vocabularies are Localized except one. The one I'm talking about has the option 'Translate'. This was done because some terms are not used or are forbidden to be used in another language. For example: In language A we have the terms a,b and c. For language B we have other terms, a,b and d. So we see that terms c and d are specific for a language. This also means that it is impossible for term d to appear on the site with language A. And that's what we want.
The awkwardness that we are now experiencing is that it's impossible to create a French node in a Dutch environment. So, if we go to domain.be/nl-BE/node/add/%content_type we can only create Dutch nodes. It is impossible to select the French term because the form returns an error. => '%vocabulary_name: illegal value'.
I will now try to use administration language but I noticed it's still in development for drupal7.
I used the Administration Language module
and the module failed. A trillion billion notices and warnings appeared.
Looking at your response I
Looking at your response I would say that the error you are getting is not the expected behavior as the Translate option should filter out any terms that are not eligible for the active language that is set.
I would also agree with @Kristen Pol that you should be looking in the issue queues to see if there are other reported issues that relate to taxonomy and/or your specific issue.
There are two things that I would verify before troubleshooting more:
I have had issues in the past where the language object ($language->language) didn't meet my expectation. The devel module is very handy for this. My issue was outside the scope of taxonomy but it did highlight that under certain conditions, the language context was not responding as expected.
You can also look at the raw source for the term and see that the language that you are setting is indeed there. If not, yet another explanation for your source of failure. At this point I would spin up a test site on a fresh install and check the steps to enabling the required modules and see if I can reproduce.
Did you manage to solve this problem?
Hi,
Did you manage to solve this problem or find a workaround? More than a year later I'm trying to make a multilingual catalog website where taxonomy is needed to categorize products and I keep getting the same issues as you described.
I did tests with localized terms and Translated terms.
When translated terms are used I too get to see for example Dutch terms when I'm editing an English node in Dutch.
This is however only an issue when you hit the edit button from the "content administration" page. But try explaining that to a client... Always an awkward moment.