When one is in the vocabulary creation form (../admin/structure/taxonomy/add) and they select the "Localize. Terms are common for all languages, but their name and description may be localized." option, they naturally expect the vocabulary to be created in the language they are currently switched to. Instead, the vocabulary is always created with the site's default language as its source.

Steps to reproduce:

1. After enabling a second language (say Italian) for the site and setting it as default, make sure you are switched to English and try to create a vocabulary under Structure -> Taxonomy -> Add vocabulary.
2. Give the vocabulary a name. Naturally, since you are in eng you'd call it for example "Colors".
3. Select the "Localize. Terms are common for all languages, but their name and description may be localized.".
4. Hit the "Save and translate" button.

Actual result:

Language           Title     Status           Operations
--------------------------------------------------------
Italian (source)   Colors    original         edit
English            Colors    not translated   translate

Expected result: Since the vocabulary was created while the site was switched to English (and given the fact that no option is provided), one would expect the source to be the English language. Instead, the source is the Italian (the site's default language).

I think that at the very least there should be an indication showing the language the vocabulary is going to be created in. It would be great though if this could be selected through a drop-down menu like we do on node creation forms.

Comments

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented
Title: Vocabularies always created in the site's default language - no matter what language you are switched to. » Allow users to select what the source language of created vocabularies will be (like we do with nodes).
Category: bug » feature

...actually, this issue's category feels kinda mixed. It starts as a bug report (legitimately IMO, since I explain the WTF the user faces with the current workflow), but it ends with a suggestion of how this might be fixed and thus gives the feeling of a feature request, so I am changing to that.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Another thing is that after all vocabulary terms have been translated, when you visit the terms list under Structure -> Taxonomy -> [vocabulary_name] -> List -> Terms (../admin/structure/taxonomy/city/list/list) the terms listed are always in the site's default language no matter what language you switch to.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

...in the node edit form the terms are displayed in the proper language though after language switching.

jose reyero’s picture

jose reyero commented
Status: Active » Postponed

The current behavior is by design, I see nothing wrong with that.

However, making the default language per vocabulary or per menu sounds like an interesting idea, which anyway needs some thinking and patches of course.

Not for the 1.0 release, maybe for next ones.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Fair enough Jose. Still, when I visit for example ../en/admin/structure/taxonomy/city/list/list I expect to see the English translated versions of the Italian terms I have under ../it/admin/structure/taxonomy/city/list/list. Both URLs list the terms in Italian though. Sorry, but I honestly fail to understand how this is intended behavior.

In the meantime can you or anybody else suggest a way to be able to alter a vocabulary's source language and make one be the source/translation of another? I know that nodes have the nid & tnid to achieve that. I can't get around how it works with vocabularies though (I see the vid but there is no tvid or anything). Thanx in advance.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Same issue when using Taxonomy manager. Both ../en/admin/structure/taxonomy_manager/voc/[voc_name] and ../it/admin/structure/taxonomy_manager/voc/[voc_name] display the terms in Italian.

jose reyero’s picture

jose reyero commented

As a general rule, stuff on admin forms is not translated. So ok, it should be, but we are not rewriting every admin form out there just for that, not to talk about admin forms for every contrib module. (Or putting it another way, it is ranking very low on our priorities).

Some related ideas here #1170850: Switching of default language causes change of source language

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Or putting it another way, it is ranking very low on our priorities...

I got that alright. It's just simply that an admin needs to somehow get an idea/overview of what is translated and what's not when it comes to things like taxonomy and menus. I wasn't thinking every single admin page out there (core/contrib). Plus it is kinda of a WTF issue, as you already seem to agree:

... stuff on admin forms is not translated. So ok, it should be,...

Thanx for linking the related issue Jose. Heading there...

jose reyero’s picture

jose reyero commented
Status: Postponed » Closed (duplicate)

Updating priorities, listening to so many requests, we'll be fixing the 'default language' issue for the 1.0 release.

For how to decide which is the 'source' language of each object (vocabulary, term, etc) this will be a good option (the other one is to stick to site default). So we are merging this issue here, open for discussion now, moved into the critical path #1170850: Switching of default language causes change of source language

As a side note, this is our absolute priority now: we need a data model that supports switching default language and that is outlined here, #1191662: Migrate away from textgroups to own storage in i18n