Closed Bug 809399 Opened 12 years ago Closed 12 years ago

Translated text is in a weird state sometimes

Categories

(www.mozilla.org :: Bedrock, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pascalc, Assigned: rik)

References

(Blocks 1 open bug)

Details

I am receiving this email error messages from bedrock-prod:

------

The translation has a different set of replaced text (aka %s)

Portions of this content are ©1998–%(current_year)s by individual mozilla.org contributors. Content available under a <a href="%(url)s">Creative Commons license</a>.
بخشی از این محتویات ©1998–%(current_year) توسط مشارکت‌کنندگان انفرادی mozilla.org ایجاد شده است. محتویات براساس <a href="%(url)s">گواهینامه Creative Commons</a> موجود است.

------

The main.lang file looks fine to me in a text editor with no error and the string I see is this one:
حقوق بعض هذا المحتوى محفوظة لمساهمي موزيلا ©1998–%(current_year)s. المحتوى مرخص وفق <a href="%(url)s">رخصة المشاع الإبداعي</a>.

I printed the string with a python-like variable replacement function on my local copy on the php side with this code and the string is correctly displayed with the right variables:

$pylike_print = function ($string, $names) {
    $string =___($string);
    foreach ($names as $k => $v) {
        $string = str_replace("%($k)s", $v, $string);
    }
    echo $string;
};

$pylike_print(
    'Portions of this content are ©1998–%(current_year)s by individual mozilla.org contributors. Content available under a <a href="%(url)s">Creative Commons license</a>.',
    ['current_year' => date('Y'), 'url' => '/foundation/licensing/website-content.html']
);

If you look at the page in production, the string is correclty displayed in Arabic with the right variables replaced:
http://www.mozilla.org/ar/apps/

So I believe that the bug is in our automatic test that report a false-positive.

Assigning to Rik since I think he wrote that test ;)
Blocks: bedrock-l10n
So the test is not broken here. The string received is invalid. The problem is why do we receive this string with a missing "s" ?
I had a failure during today's push. Let me re-run it in case that might fix things somehow.
Summary: our automatic test for variable replacements in localized string does not like rtl files → Translated text is in a weird state sometimes
So we're still getting some mails sometimes.
There is a difference between what I'm seeing in my editor and what I see in the email. In the email, it starts with "©1998–". In my editor, it starts with Arabic characters. Could it be that there's a RTL-switch character in unicode that confuses our tools?
We were on a wrong track from the start, we were looking at the wrong file, the email we receive are not for Arabic but Persian (almost the same alphabet) which does have a missing s in the variable...

Bug thanks to Anas Husseini aka Linostar, our Arabic localizer for looking into our bug :)

fixed on trunk in r110468, stage in r110469, prod in r110470

pmac will file a followup bug to improve the emails we receive and get the path of the offending file, fa/main.lang instead of main.lang in the email would have avoided helped us diagnose the problem immediately :)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 809857
You need to log in before you can comment on or make changes to this bug.