Items' titles in collages are not localizable

RESOLVED FIXED

Status

Websites
webifyme.org
P1
blocker
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: stas, Assigned: Milos)

Tracking

({l12y})

Firefox 4

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Looking at https://webifyme-dev.allizom.org/de/collage/9c7f1eda80f8/ (click any of the items in the collage), the titles of items are not localizable.

Are they coming from the DB?

This should be a blocker.  Thanks to Coce (our German localizer) for catching this.

Comment 1

7 years ago
Brez: Can you take a look at this and see why the localized strings are not being passed to that.name in /static/js/vendor/collage.js?

Thanks,
Chris
Assignee: nobody → jbresnik
Priority: -- → P1

Comment 2

7 years ago
Yea but localization is being sent in the header, it will still work regardless of whether or not the locale is in the URL..  ?

Comment 3

7 years ago
I just switched my user agent to de with the firefox add-on (https://addons.mozilla.org/en-US/firefox/addon/quick-locale-switcher/) went to the webifyme homepage. It redirected to ./de as expected. I clicked on a created collage, and when a clicked on an image the popup window had English title and German description.

It is not just the URL. The header is adjusted the site copy as expected, except for the item titles.

Comment 4

7 years ago
Cool - all set:

https://github.com/mozilla/webifyme/commit/2f648063f1b91027506b30c04382147398775e37
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 5

7 years ago
Created attachment 545766 [details]
WebifyMe localized title different

Brez: Attached is a screenshot of what I am talking about. Is that what you were seeing when you make the code change?

Updated

7 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 6

7 years ago
Its fixed - I added locale to the URL
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
FWIW, the strings still are not in the po file, so I still can’t localize them.
(Reporter)

Comment 8

7 years ago
(In reply to comment #6)
> Its fixed - I added locale to the URL

That's a good change for performance (avoids implicit locale detection), but I'm not sure it is the right fix for this bug.

Looking at https://github.com/mozilla/webifyme/blob/master/ff4/things/fixtures/images.yaml it seems that the names of the images are 'hardcoded' in the fixture (and, thus, in the DB as well I presume?).  For instance:

> - fields: {file_name: 1755_site_0043.png, height: 113, locale: null, name: Cereal,
>    slug: 1755_site_0043png, width: 98}
>  model: things.image
>  pk: 62

In order to localize them, we should have a place (possibly a separate file akinn to questions_answers.py) where all these names are stored in the Python code and wrapped in gettext function calls _().  This will allow us to extract them into the PO files and the localizers to translate them.

Then, in the code that is responsible for displaying the images, we should use _() again, like so (pseudocode):

> title_in_English = Image.objects.get(pk=62).name
> title_to_display = _(title_in_English)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 9

7 years ago
> That's a good change for performance (avoids implicit locale detection), but
> I'm not sure it is the right fix for this bug.

It's exactly how we're doing it for navigation on the rest of the site..  i.e. what is the right fix?

> yaml it seems that the names of the images are 'hardcoded' in the fixture
> (and, thus, in the DB as well I presume?).  For instance:

Youre saying this is why we see English titles and German text?

Comment 10

7 years ago
> That's a good change for performance (avoids implicit locale detection), but
> I'm not sure it is the right fix for this bug.

It's exactly how we're doing it for navigation on the rest of the site..  i.e. what is the right fix?

> yaml it seems that the names of the images are 'hardcoded' in the fixture
> (and, thus, in the DB as well I presume?).  For instance:

Youre saying this is why we see English titles and German text?
(Reporter)

Comment 11

7 years ago
(In reply to comment #9)
> > That's a good change for performance (avoids implicit locale detection), but
> > I'm not sure it is the right fix for this bug.
> 
> It's exactly how we're doing it for navigation on the rest of the site.. 
> i.e. what is the right fix?

This is all good, but I don't see how it's related to this bug?


> > yaml it seems that the names of the images are 'hardcoded' in the fixture
> > (and, thus, in the DB as well I presume?).  For instance:
> 
> Youre saying this is why we see English titles and German text?

That would be my guess.  I don't know how the code works exactly, but I do know that the titles are currently not in the PO files, which means that they are not extractable, and thus, not localizable.

Comment 12

7 years ago
> 
> This is all good, but I don't see how it's related to this bug?

It's not but we initially thought it was..


> That would be my guess.  I don't know how the code works exactly, but I do
> know that the titles are currently not in the PO files, which means that
> they are not extractable, and thus, not localizable.

Ill move them out as suggested..

Comment 13

7 years ago
Stas: How much extra time will this added to get German locale timeline once the strings are available in the PO file?

Comment 14

7 years ago
Stas - all set:

https://github.com/mozilla/webifyme/commit/e3ad2c5b69253e196bb1d769623b1f8666bed553

I'll reassign this to Stas since he need to coordinate the translation.

Updated

7 years ago
Assignee: jbresnik → stas
(Reporter)

Comment 15

7 years ago
Thanks brez.

I haven't tested the code yet, but I wonder if you need to do the _() in views.py in this setup.

> lang_specific_name = _(force_unicode(IMAGES[image.file_name]))

Since IMAGES already has lazy translations as value, I think _() is not necessary here.  In fact, it may be a bug, calling _(_(...)) will try to look for translations of the translated string.

I think this should work:

> lang_specific_name = force_unicode(IMAGES[image.file_name])

An alternative would be to do this:

> lang_specific_name = _(image.name)

Thoughts?

Comment 16

7 years ago
Milos: This is another L10N issue that need resolved. It is a blocker.
Assignee: stas → milos

Comment 17

7 years ago
Created attachment 546799 [details]
German locale and en-US titles and description.

Here is a screenshot of what I now see on dev. Notice that my locale is set to German in the bottom right and some of the text is localized.

Comment 19

7 years ago
@Chris - You won't see German there until the translations are complete..
If I may say so, the German translation *is* complete. See <https://localize.mozilla.org/de/webifyme/>
Still, it seems like the translations aren’t used on the website. And right now, the quiz itself doesn’t seem to work. Error 500 …
(Assignee)

Comment 21

7 years ago
(In reply to comment #20)
> If I may say so, the German translation *is* complete. See
> <https://localize.mozilla.org/de/webifyme/>
> Still, it seems like the translations aren’t used on the website. And right
> now, the quiz itself doesn’t seem to work. Error 500 …

@Coce, I'll update templates on verbatim today, and will ping you once I'm done so you can double check your translations and translate any new strings out there.

@brez, I have just tried to extract strings into temlate.pot, but got nothing. Would you please ping me on IRC when you can so we can figure this out.

BTW, Stas is on vacation since Sunday.
(Assignee)

Comment 22

7 years ago
As per r92598, it looks like Stas fixed it. We're done here. Thanks people!
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
The translated strings still aren’t visible on the website, though.
You need to log in before you can comment on or make changes to this bug.