[regression] some translated pages are displaying english for for certain languages



2 years ago
a year ago


(Reporter: pmac, Assigned: pmac)



Firefox Tracking Flags

(Not tracked)



(1 attachment)

Created attachment 8772651 [details] [review]
Link to Github pull-request: https://github.com/mozilla/bedrock/pull/4230

I recieved the following in an email:

> On 19/07/16 22:26, Michael Wolf wrote: 
> Hi. 
> I had translated the SMARTON pages into dsb and hsb: 
> https://www-dev.allizom.org/dsb/teach/smarton/ 
> https://www-dev.allizom.org/dsb/teach/smarton/security/ 
> https://www-dev.allizom.org/dsb/teach/smarton/tracking/ 
> https://www-dev.allizom.org/dsb/teach/smarton/surveillance/ 
> Suddenly these pages are in English only, even on staging server 
> dev.allizom.org. What did happen? I hope I haven't done the work all in 
> vain. The pages were in Sorbian until today, even on mozilla.org.

What happened was that a change was made to bedrock to change some of our i18n machinery. This caused a greater reliance on Django's default i18n code, which was only respecting languages for which it had some default translations. We have more languages than the Django project, so this resulted in some languages (e.g. "dsb" and "son") no longer showing translated text. The attached pull-request fixes this issue and it should be in production soon.
This change is now live on all bedrock environments (dev, stage, and prod). Please comment here if any further regressions in this area are noticed.

I'm leaving this bug open for now because the new changes need more tests to ensure this doesn't happen again.
Assignee: nobody → pmac

Comment 2

2 years ago
Thanks for the quick fix.

There's an upstream django ticket on our problem here, https://code.djangoproject.com/ticket/25223. I find the ticket confusing, though.

Comment 3

2 years ago
The funny point is that Django has been already translated into dsb and hsb for some weeks and, most probably, Django 1.10 will come in dsb and hsb as well.
The main point though is that we don't want to rely on the languages into which Django has been translated since that is irrelevant to our project. And I think the change we just made has (re)accomplished this.
(In reply to Axel Hecht [:Pike] from comment #2)
> There's an upstream django ticket on our problem here,
> https://code.djangoproject.com/ticket/25223. I find the ticket confusing,
> though.

That does seem to be a symptom of the same issue that we had, though they are different manifestations. The strange thing about bedrock is that we don't use Django's i18n machinery much at all. It relies on .po files and a typical gettext workflow, and we have a lot of custom code that allows us to use .lang files. The only bit of the default stuff that we do use is the string extraction stuff, but even that is heavily augmented by Babel and Puente. So it was a mistake in the first place to rely on Django for translation activation and this issue just highlighted that. The code is now much more simple and efficient as a bonus.

Comment 6

2 years ago
The reason why I translated Django was AMO. There some date strings are used and I was told that they come from Django. Therefore they were - and still are - untranslated:


It is about the links under "Nowinki wuwiwarjow". It is bad there because there are strings in English as "2 days, 14 hours ago". English uses a postposition here and has no inflection. But Slavic languages as the Sorbian languages use prepositions which require a certain grammatical case. Upper Sorbian uses the preposition "před" (ago, before) plus instrumental. Unfortunately the prepositon "před" comes from Mozilla = Pontoon but the date expressions come allegedly from Django. I think it's bad to use such mixed contents here and even in one string.
I agree. Hopefully they can get AMO's Django upgraded or include your new translations some other way. Thanks for the help, and again apologies for the regression on www.m.o.

Comment 8

2 years ago
No problem, Paul. The issue was fixed very quick. It is really a pleasure to work together with you L10n drivers.
This seems to have been working well for a few months now. Safe to close I think. Thanks again.
Last Resolved: a year ago
Resolution: --- → FIXED

Comment 11

a year ago
Yes, Paul, the issue from your description above is  resolved. But this from comment #6 not, but I think AMO drivers have the responsibility here.
Oh right. If there is something AMO can do about that it'd be best to have a bug filed against their component for them to track. I'm actually not sure which component that might be, but I can find out if you need me to. Hopefully they or their l10n drivers are already tracking that issue.

Comment 13

a year ago
I opened bug https://github.com/mozilla/addons-server/issues/2794 in May which has already been closed. I think I will file a new bug.
You need to log in before you can comment on or make changes to this bug.