Some localized strings are not extracted (and therefore not localized)
willdurand opened this issue · comments
We use oneLine for some of our localized strings but that breaks the extraction task. This isn't exactly a new issue (see: mozilla/addons-frontend#2108) but we never noticed that we had the same problem in this repo. Let's fix it.
For QA: we expect more strings to be localized in the near future (e.g. in Italian). We can verify that by running the linter with a LC_ALL env var:
LC_ALL=it_IT addons-linter addon.xpi
┆Issue is synchronized with this Jira Task
I tried on linter 6.1.0 with your example, it says LC_ALL is not recognized
If I reverse it and run it, I get the validation summary
@willdurand Sorry I did not check the release date of the linter, the current version needs an update.
I think, in this case, it does not matter since the LC_ALL env var is probably not recognized on Windows...
I asked @acornestean to check this on MAC OS, he did not get errors but with LC_ALL=it_IT or LC_ALL=de_DE the messages are returned in en-US
Indeed... I can reproduce too. That does not look too great :(
@ioanarusiczki addons-linter v6.3.1 should fix this problem (hopefully)
We might have another bug here[^1] but at least we can verify this issue with:
LC_ALL=it addons-linter /path/to/some/extension
This has been re-checked by @acornestean and with LC_ALL=it or LC_ALL=de translations are available:
@willdurand About your comment
When I tried with LC_ALL=pt_PT or LC_ALL=pt_BR it returned translated strings. pt_PT or pt_BR dialects are also available on AMO
AMO does not have it_IT , (it's just it) , or de_DE so perhaps that's why it doesn't work when I use them in that format.
Yeah, this is more or less the reason. We have both individual locale codes (ISO 639-1) and locales with country codes (e.g. pt_PT). That being said, I think LC_ALL is often configured with locale + country code so for a user who has LC_ALL=fr_FR, it'd be good to default to fr.