BazingaJsTranslationBundle
BazingaJsTranslationBundle copied to clipboard
willdurand
Locales with region are not supported
Hey, when I have my html lang attribute defined as "de-DE", which is correct, according to http://www.ietf.org/rfc/bcp/bcp47.txt and import translations for "de" (), then Translator.trans('MyMessage') returns message in default language (I expect it to return them in german).
Hello there
I'm facing a similar problem.
Our app allows "en_GB" and "en". We support other flavours of English so that dates and money values, for example, are correctly localized. To make things easier, all English translations are currently stored in "en" files.
I'm running the latest version of the bundle. When I request "en_GB" translations, I don't get the "en" translations. By the way, I'm expecting the "en" translations only because that's what Symfony would give me. Even with the fallback locale set to "en", I don't get the "en" translations.
Is that expectation unreasonable: should I expect to get the "en" translations if there aren't any "en_GB" translations? (I mean: it may be undesirable get something other than specifically what you asked for.) One way or another, I'll fork the code and see if I can find a sensible solution for us. I'll perhaps issue a PR after.
Thanks very much for the bundle, by the way. We've found it really useful and are happily using it through RequireJS.
Best, Dan
I think it only works well the other way around for now. How does Symfony translator behave?
Symfony translators looks first for messages.de_DE.yml, then messages.de.yml.
Yes, because it is the format that Symfony supports for its locale. Valid "lang" attribute value for
tag is "de-DE".
I think adding this behavior should not be too much work as the Translator is well-tested. Anyone willing to help on this?
Afternoon, both.
I've just pushed some changes to my fork of the repository. See https://github.com/powderblue/BazingaJsTranslationBundle. I tried a couple of approaches before going with this - what I think is fairly un-instrusive. I don't doubt, however, that things could be improved and I realise this is only a part of the solution.
So far, these changes appear to have solved my problem: when my app is operating in the "en_GB" locale I will get translations for "en" if translations for the requested locale are not available.
Dan
LGTM, with one little exception. The correct format for lang attribute in HTML is en-GB, not en_GB (http://www.w3.org/TR/html5/dom.html#the-lang-and-xml:lang-attributes, http://www.ietf.org/rfc/bcp/bcp47.txt).
I'm facing the same problem at the moment.
@danbettles Can you open a PR so we can discuss this further? It should work with <html lang="en-GB"> instead of <html lang="en_GB">.
I've updated my version of the code but I want to carry out some additional tests. I'll get back to you guys as soon as I can. In the mean time, perhaps you could try out my fork, see if it works for you.
Thanks.
I took another approach with just updating the Javascript in #143.
Now I can load nl + nl_BE and it works :)
Poke @willdurand 😃 We have the same need here, and the feature is still opened for more than a year now ! May be we should merge the @ruudk work https://github.com/ruudk/BazingaJsTranslationBundle/commit/1253ab4a2969cd0cba794ab675fbefa0ac702cb9 inside the current official repository.
What do you think ? Thanks everybody for this project !
I'm still having troubles with this issue.
My Symfony code only has a messages.fr.yml file. If the requested locale is fr_BE, the generated translations.js file is empty except for this:
(function (t) {
t.fallback = 'en';
t.defaultDomain = 'messages';
// fr_BE
})(Translator);
It completely ignores the messages.fr.yml file unless the requested locale is fr (or the file is renamed as messages.fr_BE.yml but I don't want to duplicate translation files).
I could get around it with the attached patch but I'm pretty sure it isn't the way to go. It stores all the messages under the requested locale (fr_BE in my case) so Maxooo's patch is unable to distinguish the genuine fr_BE messages from those from the fr file. This is not a problem to me because I have no messages.fr_BE.yml file.
@Maxooo how do you end up with the base language (fr) translations in translations.js so that your patch can fall back to it if the fr_BE message isn't found?
@fmarchalemisys fork it, apply following patch https://github.com/simplesurance/BazingaJsTranslationBundle/commit/1d4aa1940b7bb55e7ec376369fcd0f2e1d5f8b27, profit.
Hi,
@fmarchalemisys I don't really remember since I worked on this, but in fact (and you're right) I used the tow parts local to deal with translations (i.e. fr_FR). Is it SF compliant to use short local expression (i.e. fr) ? It doesn't appear clearly : http://symfony.com/doc/current/translation.html#fallback-translation-locales
I found a working solution. All I had to do was to add the "locales" parameter when loading translation.js:
{% set locales = app.request.locale|fullLocales %}
<script src="{{ url('bazinga_jstranslation_js', { 'locales': locales|join(',') }) }}"></script>
Here, locales ends up as an array containing ['fr_BE','fr'] in that order.
I then load another translation.js containing the fallback locale:
{% if fallback_locale not in locales %}
<script src="{{ url('bazinga_jstranslation_js', { 'locales': fallback_locale }) }}"></script>
{% endif %}
The fallback locale isn't in the same file as the requested locales because it won't change if the user switches to another language.
Just to be complete, here is the fullLocales twig extension I used above.
public function fullLocales($locale)
{
$locales = array();
$locList = explode(',', $locale);
foreach ($locList as $loc)
{
$locales[] = $loc;
$language = \Locale::getPrimaryLanguage($loc);
if ($language !== $loc)
$locales[] = $language;
}
return $locales;
}