Hi,
winterfairy@??? wrote (02 Nov 2013 11:54:17 GMT) :
> Kevin wrote:
>> The root of the problem here is the locale-dependent strftime string.
>> Typically these are in the form of "%a %b %e %H:%M:%S" or something
>> along those lines.
>>
>> [...]
>>
>> Programmatically supporting this is impractical which led me to examine
>> the source code for the official GNOME panel clock applet. Basically,
>> they support the formats via translation strings.
>>
>> I will now head down the path of supporting the date/time formats via
>> translation strings.
> This sounds like a good solution to me.
Agreed.
>> As a bonus, I'll follow the same design pattern as
>> the GNOME clock applet and we can "borrow" the translation strings from
>> them (both projects being GPL, I don't believe this should be an issue,
>> please correct me if I'm wrong).
Great idea, so that most languages get a correct display right from
the beginning. Bonus points for scripting this import process, so that
we can get their updated in the future.
>>> If standalone like now, we need to get Runa or someone to add a new
>>> translation resource on Transifex for it. In this case, which repository
>>> and which branch should we be tracking the pot file in?
>>
>> tails at git.tails.boum.org:kevin/clock.git
>>
>> The stable branch is "master".
> If I get the clear sign from a "higher-up" Tails dev that this is the way
> to do it, I volunteer to contact Runa and get it added. :)
I confirm this is the right way to do it. However, it seems a tiny bit
premature to me: to avoid translators doing unnecessary work,
I suggest we only do that once the applet has sajolida has had time to
review the UI and the strings.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
