1018130 - hi-IN - TB AB quicksearch broken in Hindi due to translated operator in search URL (mail.addr_book.quicksearchquery.format); and more unwanted translations of "true/false" settings

Status: RESOLVED FIXED

(Mozilla Localizations :: hi-IN / hindi, defect)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #1018087 +++

In Hindi locale, AB quicksearch must be completely disfunctional, because there's translated content in mail.addr_book.quicksearchquery.format which must NOT be translated:

http://lxr.mozilla.org/l10n-central/source/hi-IN/mail/chrome/messenger/messenger.properties#214
> mail.addr_book.quicksearchquery.format=?(या(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V))

Actual:   ?(या(...
Expected: ?(or(...

As a separate but similar bug, some boolean settings are broken because their values have been translated (but must remain English because they are internal settings which do not show up in the UI):

http://lxr.mozilla.org/l10n-central/source/hi-IN/mail/chrome/messenger/messenger.properties#203
mail.addr_book.displayName.lastnamefirst=गलत

http://lxr.mozilla.org/l10n-central/source/hi-IN/mail/chrome/messenger/messenger.properties#216
mail.addr_book.show_phonetic_fields=गलत

Aceman, thanks for correcting product/component on the other bug.
Shouldn't we add a comment here that the entire content of mail.addr_book.quicksearchquery.format must not be translated, only supplemented when mail.addr_book.show_phonetic_fields=true ?

Same for the boolean issue, there's no explicit comment for localizers that this must not be translated (the English comment which is there won't be very clear when you're not too familiar with English).

Comment 1

[Thomas D. (:thomas8)]

> mail.addr_book.displayName.lastnamefirst=गलत
> mail.addr_book.show_phonetic_fields=गलत

Expected "localizations" of the boolean strings must be in English, but the localizer should chose the appropriate behaviour for his language by picking either "true" or "false":

mail.addr_book.displayName.lastnamefirst=true
OR
mail.addr_book.displayName.lastnamefirst=false

mail.addr_book.show_phonetic_fields=true
OR
mail.addr_book.show_phonetic_fields=false

Comment 2

[Thomas D. (:thomas8)]

Ace, in addition to my other question above, where do I find localizers as assignees for these bugs?

Comment 3

[Francesco Lodolo [:flod]]

Technically they should find you, since this is their component.

Having said that, I don't think we're actually shipping Thunderbird for hi-IN (and af is ages behind)
https://l10n.mozilla.org/teams/hi-IN

I'm not familiar at all with Thunderbird, I assume this should be list of locales we're shipping
http://hg.mozilla.org/releases/comm-release/file/c4c80b09c5a0/mail/locales/all-locales

Comment 4

[:aceman]

(In reply to Thomas D. from comment #0)
> Aceman, thanks for correcting product/component on the other bug.
> Shouldn't we add a comment here that the entire content of
> mail.addr_book.quicksearchquery.format must not be translated, only
> supplemented when mail.addr_book.show_phonetic_fields=true ?
> 
> Same for the boolean issue, there's no explicit comment for localizers that
> this must not be translated (the English comment which is there won't be
> very clear when you're not too familiar with English).
Yes, that would be fine. Good job finding out these problems.

(In reply to Thomas D. from comment #2)
> Ace, in addition to my other question above, where do I find localizers as
> assignees for these bugs?
I don't know but usually they come themselves and comment into the bug. They probably have watches set on the product/component.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Francesco Lodolo [:flod] from comment #3)

Thanks Francesco for quick reply. 

> Technically they should find you, since this is their component.
> 
> Having said that, I don't think we're actually shipping Thunderbird for
> hi-IN (and af is ages behind)
> https://l10n.mozilla.org/teams/hi-IN
> 
> I'm not familiar at all with Thunderbird, I assume this should be list of
> locales we're shipping
> http://hg.mozilla.org/releases/comm-release/file/c4c80b09c5a0/mail/locales/
> all-locales

Can someone comment if this is the definite list for TB? I see "Seamonkey" comments around there...
Anyway, even in that list we have locales affected by the same problem reported in this bug, and I think this bug should be rooted out whereever we find it, sleeping localizations or not. If these ever ship, it will be very hard to discover the problem.

Comment 6

[:aceman]

I think I replied here.

You can ask standard8 about the release problems and how to address a bug that is in many localizations at once. I assume you do not feel great about filing a bug for each of the languages.

Comment 7

[Mark Banner (:standard8)]

http://hg.mozilla.org/releases/comm-esr24/file/default/mail/locales/shipped-locales is the current list of shipped-locales. hi-IN isn't one of them. For it to be added, one of the things we'd have to do is to review all of the locale files and generally check it works ok, so this would likely be picked up.

Comment 8

[:aceman]

I don't think this bug would be found by a "general check". It does not produce any visible breakage whatever the value is. Just from the start of the list, "ar" and "bg" are shipped and do have the bug. Continuing with "ca", "es-*"...

So how do we mass fix ~10 localizations? Should we just file 10 bugs ?

Comment 9

[Mark Banner (:standard8)]

Filing bugs is fine.

Comment 10

[Francesco Lodolo [:flod]]

Hindi is not shipping in Thunderbird, and it's not enabled in localization tools like Pontoon.

I'm going to remove the strings frome Mercurial, in case someone decides to pick up the localization.
https://hg.mozilla.org/l10n-central/hi-IN/rev/c545f623fef8c9896eaa22335af06947ad52ec05