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 ;)

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.

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 :)