[Sugar-devel] [PATCH](Clock) Fixing an instance (australian case) of http://bugs.sugarlabs.org/ticket/2944

[Chris Leonard]

This may be the Python way

http://docs.python.org/library/locale.html

http://docs.python.org/release/2.2.3/lib/module-locale.html

cjl


On Fri, May 11, 2012 at 12:58 AM, Chris Leonard
<cjlhomeaddress at gmail.com> wrote:
> On Fri, May 11, 2012 at 12:42 AM, Rafael Ortiz
> <rafael at activitycentral.com> wrote:
>>
>>
>> On Fri, May 11, 2012 at 1:19 AM, Chris Leonard <cjlhomeaddress at gmail.com>
>> wrote:
>>>
>>> I do not like the idea of special casing en_au at all, the proper way
>>> to fix this is to get the i18n correct in the first place and not
>>> thrown in special cases.
>>>
>>> a) I thought that the Aussies were using the en_GB strings, which
>>> should have the dd/mm/yy format they are looking for, whcih it would
>>> if the string were not too difficult for localizers to figure out,
>>> both fo these strings are wrong and the comment is inadequate.
>>>
>>> en_GB
>>>
>>> http://translate.sugarlabs.org/en_GB/honey/clock.po?item=3&view_mode=translate
>>>
>>> en_US
>>>
>>> http://translate.sugarlabs.org/en_US/honey/clock.po?item=3&view_mode=translate
>>>
>>> Besides the fact that localizers have difficulty wi h the markup, we
>>> shouldn't be asking localizers for time and date format at all, this
>>> should come directly from glibc locale LC_TIME Date format (d_fmt)
>>> field
>>>
>>> which is
>>>
>>> %m/%d/%Y for en_US
>>>
>>> and
>>>
>>> %d/%m/%y for en_AU
>>>
>>> cjl
>>> Sugar Labs Translation Team Coordinator
>>>
>>>
>>>
>>
>> Hi Gary and Chris
>>
>> Thanks for the comments i agree with what both are saying, I had to do this
>> change in order to clock get the proper ordering here,
>> this is somewhat failing even thought the string is translated (en_GB)
>> variant.
>> still I need to investigate cjl's resources.
>
>
> http://www.gnu.org/software/libc/manual/html_node/The-Elegant-and-Fast-Way.html#The-Elegant-and-Fast-Way
>
> This link is a good place to start for how to do this, not sure if
> there are special methods for Python, but there maybe.  I'm really not
> much of a programmer anymore :-(
>
> The general idea is that this data already exists in glibc locale
> files, that is what glibc locales are for, and we should use it to
> avoid recreating glibc locales wherever possible.  This also reduces
> the workload on localizers.
>
> Using glibc data callouts should solve the general case and eliminate
> the need for special cases.  If there is no glibc locale, we're
> screwed anyway and need to create one.
>
> I'll be filing a similar bug against timeline i18n.
>
> cjl