This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] fi_FI: Define yesstr, nostr
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: myllynen at redhat dot com
- Cc: Keld Simonsen <keld at keldix dot com>, libc-alpha at sourceware dot org
- Date: Wed, 20 Mar 2013 18:54:32 -0400
- Subject: Re: [PATCH] fi_FI: Define yesstr, nostr
- References: <5141EF6D dot 9000601 at redhat dot com> <514334DF dot 8000306 at redhat dot com> <51434336 dot 3020103 at redhat dot com> <5149DAAA dot 9060309 at redhat dot com>
On 03/20/2013 11:50 AM, Marko Myllynen wrote:
>>> (a) Include in a comment the unicode values of yesstr/nostr, this makes
>>> review easier for future readers.
> I'm not sure is this really needed, see below.
It's a convenience to have the the full string in a comment
above the encoded string in the locale.
>>> (b) Can you build the library to make sure the locale is compiled correctly
>>> and without error?
> I think the most efficient way to test such an isolated locale change is
> to do something like the following (which is what I've used now and in
> the past):
> localhost:~> unset LANG LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_TIME
> localhost:~> LOCALE=fi_FI
> localhost:~> export I18NPATH=$HOME/locale-test/
> localhost:~> export LOCPATH=$HOME/locale-test/
> localhost:~> mkdir -p $LOCPATH
> localhost:~> localedef -f UTF-8 -i ./$LOCALE $I18NPATH/$LOCALE.UTF-8
> localhost:~> LANG=$LOCALE.UTF-8 locale -ck LC_MESSAGES
> This also makes it as easy as an comment to review these particular values.
>>> I've included Keld in the TO since as the author of the locale it would
>>> be nice if he could comment on the change.
>>> After review, and once we checkin your changes you should update the BZ
>>> to indicate you've fixed fi_FI.
> Review is good but were you aware that you are asking a non-native
> speaker to review the translation of Yes/No by a native speaker?-) More
> seriously, the translations I've provided are also present in the CLDR
> data for fi.
I'm involving Keld because he helped with the original contributions
and has been responsive and helpful with review.
The fact that this is present in CLDR is the more important data point.
I'm going to assume that CLDR is authoritative here.
I do agree with your recent comment about the fact that most experts
contribute to CLDR, and ICU also considers them canonical.
I'll get this checked in ASAP.