#7800 HIGH 8.2.0 (: time stamps doesn't use translations

Zarro Boogs per Child bugtracker at laptop.org
Tue Aug 5 23:49:45 EDT 2008


#7800: time stamps doesn't use translations
----------------------+-----------------------------------------------------
   Reporter:  khaled  |       Owner:  tomeu               
       Type:  defect  |      Status:  new                 
   Priority:  high    |   Milestone:  8.2.0 (was Update.2)
  Component:  sugar   |     Version:  not specified       
 Resolution:          |    Keywords:                      
Next_action:  code    |    Verified:  0                   
  Blockedby:          |    Blocking:  6808                
----------------------+-----------------------------------------------------

Comment(by dupuy):

 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
 subsititution.  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 gettext / libc-stdio /
 Python 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, Devangari, 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

-- 
Ticket URL: <http://dev.laptop.org/ticket/7800#comment:5>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system


More information about the Bugs mailing list