[Localization] Untranslated timestamps in Journal

[Alexander Dupuy]

Khaled Hosny writes:
> I opened a ticket with a patch, but it lead to another problem, see my
> comment http://dev.laptop.org/ticket/7800#comment:1. I appreciate if
> some one else can test/investigate this.
>   
Khaled - the problem with the "not all arguments converted" is due to 
missing %d in some of the plural forms of the Arabic translation (I 
don't know why this wasn't caught by the Pootle automated checks that 
Sayamindu runs - or maybe it would be caught by them, but you didn't run 
them before committing)

If you look at 
https://dev.laptop.org/translate/ar/xo_core/sugar-toolkit.po?translate=1&view=1&pofilename=sugar-toolkit.po&item=20

you'll see that
%d year
is translated for different plural forms as:
Plural Form 0
%d سنة
Plural Form 1
سنة
Plural Form 2
سنتين
Plural Form 3
%d سنوات
Plural Form 4
%d سنة
Plural Form 5
%d سنة

note that the plural form 1 and plural form 2 do not have the %d marker. 
I suppose (I'm not an Arabic speaker) that these are something like "a 
year" and "a pair of years" - which may well be more idiomatic Arabic, 
but cause errors due to the lack of the %d parameter for numeric 
substitution. When the TypeError is thrown as a result, the rendering 
aborts, and you may not be seeing anything at all (except the error in 
the logs).

While it may lead to less idiomatic translations, please retranslate 
these strings in some form (whatever form) that includes the %d for all 
plural forms, including forms 1 and 2. When you commit this fix to the 
translations and run with the updated language packs, this problem 
should go away.

The requirement for numeric substitutions in all plural forms is 
arguably a bug/misfeature of the GNU gettext / Python i18n/l10n system - 
feel free to submit a feature request to the maintainers of either to 
support a substitution suppression format code, so that you can write 
something like
%*dسنتين
and have the %*d satisfy the numeric substitution but expand into an 
empty string.

While you're editing these translations, I wonder if you should use %Id 
rather than %d to get Arabic-Indic digits (۰۱۲۳۴۵۶۷۸۹) rather than Latin 
digits (0123456789). Hmmm...just tried that out, and although C's 
sprintf (on my Fedora 7 system) uses the Arabic-Indic digits for %Id 
when the locale is set to "fa_IR" (but not "fa" or "ar"), Python just 
spits out:

ValueError: unsupported format character 'I' (0x49)

so I guess the answer to this is no. If using Arabic-Indic digits would 
make the Journal more kid-friendly, you might want to file a separate 
(low-priority) ticket about this, since it would require extra 
locale-specific work (for Arabic, Thai, Devanagari, and other languages 
with their own digits).

On a slightly tangential note, I wonder whether it would make sense to 
add explicit RTL markers to these translations; while the substituted 
numeric characters will be output LTR (numbers are LTR in Arabic; only 
text is RTL), the translation strings display in Pootle as
%d ...
until you edit them, at which point they are displayed as
... d%
which more accurately reflects the order of the bytes (in overall RTL). 
Having the explicit RTL markers might make the display more consistent. 
I suppose it might mess up the numbers normal LTR order, though.

@alex


-- 
mailto:alex.dupuy at mac.com