Bug #8273

i18n mapping problems with Hungarian

Added by Dan Gillean about 7 years ago. Updated almost 7 years ago.

Status:VerifiedStart date:04/13/2015
Priority:MediumDue date:
Assignee:-% Done:


Target version:Release 2.2.0
Google Code Legacy ID: Tested version:2.2
Sponsored:No Requires documentation:


First reported in the User forum: https://groups.google.com/d/msg/ica-atom-users/tojHh9Y3y2k/uIsdSPyRgNQJ

I installed Atom 2.1.2 and it works well with default settings. After that I add Hungarian language in settings menu. It looks it installed it successfully, but it doesn't work. And the problem is, the Hungarian culture code is hu_HU, but after changing language, the sf_culture option in the URL is only hu. In the database the translation codes are correct (hu_HU), that's why they not worked. In the i18n directory there is also a hu_HU named folder. When I change the code in the URL manually, the translation works fine, but the links not. I wonder how can I change somehow the sf_culture code, or where are these country codes stored?

I asked the user to make sure that they had repopulated the index after adding Hungarian, and tested myself:

I did try testing this locally, and encountered some issues - though exactly the same ones you report. After adding Hungarian via Admin > Settings > i18n languages and then rebuilding the search index, I noticed that switching to Hungarian would not bring up the translation bar, the same way that switching to French will, for example. The setting would also not stay when I switched pages. I tried manually changing the URL as you suggest, but I saw little difference - in both cases, the only translated string I could easily find browsing through the interface was in the Language facet - English appeared as "angol" instead - but this worked whether I used "hu" or "hu_HU".

The user got back to us and said he did rebuild the index, etc:

Yes, I rebuild the search index and clear the cache every time. As I noticed, the translation of the menu points and some strings are stored in the MySQL database, and that didn't work either in the default way. After changing the code they did. I installed Brasilian Portugese language, to try, because I noticed that use the same format (pt_BR). But it works well, even in the installed languages list the code is pt_BR.

Ideally we can figure out how to resolve this. Assigning to Radda to take a look.


#1 Updated by José Raddaoui Marín about 7 years ago

Hi Dan, there is a discrepancy between the code used in Transifex and the one used in Symfony for the Hungarian language.

The translations from Transifex are added using 'hu_HU', this includes the folder with the messages file here and the translations for the menus, terms, etc. that are added to the database in the install process via fixtures, for example here

Otherwise, when the Hungarian language is added in AtoM, Symfony uses 'hu' for the language setting value, for the new translations added to the database and for the culture parameter in the URL. In consecuence, the Elasticsearch index is using 'hu' too.

Fixing it in 'stable/2.1.x' would take at least four hours. Renaming the folder from 'hu_HU' to 'hu' will only fix some of the strings in the interface. To fix the translations for the menus, terms, etc. we will need a migration script and they will need to be fixed in the fixtures files too, for new installations.

I don't know a lot about Transifex but, for the 2.2 version, I guess/hope we can bring the Hungarian translation using 'hu'. That would make everything work.

About the culture parameter sent in the URL, once it's sent it's stored internally and removed from the URL; the culture won't change until it's sent again with another value.

Please, let me know if we should fix it in stable/2.1.x.

#2 Updated by Jesús García Crespo about 7 years ago

Hey Radda before you go ahead with the suggested changes could you please investigate why in the i18n settings the Language code dropdown doesn't let us select both hu and hu_HU? Both seem to be available in the data/ directory of the framework, see hu.dat and hu_HU.dat.

Ideally the dropdown should include both hu and hu_HU, right?

#3 Updated by Jesús García Crespo about 7 years ago

It seems that the list is built around here: sfCultureInfo::findInfo().

#4 Updated by José Raddaoui Marín about 7 years ago

  • Assignee changed from José Raddaoui Marín to Jesús García Crespo

After discussing this with Jesús, we realize that adding hu_HU would require a significant amount of work in the Symfony framework, and we don't even know if there is a difference. At this point, the easiest is to move the Transifex team from hu_HU to hu (using import and export) and before the release making sure in AtoM that the i18n catalogues are also updated (remove hu_HU/ and import hu/ from Transifex instead).

#5 Updated by Jesús García Crespo almost 7 years ago

  • Assignee deleted (Jesús García Crespo)

#6 Updated by Dan Gillean almost 7 years ago

  • Status changed from New to Verified

Mke G and David have exported the hu_HU translations, re-imported them into HU, deleted the hu_HU project, and invited all the users to the hu project. Hopefully this should merge into AtoM properly now.

Also available in: Atom PDF