[Localization] Untranslated timestamps in Journal

[Khaled Hosny]

On Tue, Aug 05, 2008 at 11:51:24PM -0400, Alexander Dupuy wrote:
> 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)
I think this is valid for C at least (I used this many times with gnome),
it may be a python specific issue.

> 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.
Putting the numbers will make a very bad translation, some thing like
saying 2 day in English.

>
> The requirement for numeric substitutions in all plural forms is  
> arguably a bug/misfeature of the GNU gettext / Python i18n/l10n system -  

I think this a bug in python's gettext implementation, since this is
allowed in C.

> 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.

I tried %.d which I supposed it would suppress printing the number, but
it made no difference, however %.s does the trick. Now I'm wondering how
bad is that since msgfmt -c gives "fatal errors" but python didn't
complain so fare.

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

%Id isn't supported in python, also Arabic glibc locale definitions
lack the needed support (can be fixed though). IIRC some one had a patch
for this in python, I'll try to check this.

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

Yes this is important for children in Egypt and the rest of Arabic world
to the east of it, I don't know why I forgot this.

>
> 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.

AFAIK numbers are weak LTR characters, so when followed by strong RTL
the overall direction will be RTL (and this what actually happens).

Regards,
 Khaled
>
> @alex
>
>
> -- 
> mailto:alex.dupuy at mac.com

-- 
 Khaled Hosny
 Arabic localizer and member of Arabeyes.org team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.laptop.org/pipermail/localization/attachments/20080807/9e586bf2/attachment.pgp