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

[Chris Leonard]

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