On 09/20/2010 10:44 AM, John Dennis wrote:
On 09/20/2010 10:19 AM, Adam Young wrote:
On 09/20/2010 10:07 AM, Rob Crittenden wrote:
And a small nit. The help for the argument says 2-character language
code. This ignores the language subtags (e.g. en-US).

If we get to the point that we are differentiating between en_US and
en_AS, we will have won this battle.  I'll update the Docs once we start
doing locale specific files!

FYI, I have seen i18n fail when the country code (i.e. dialect) is omitted and only the language code is used. One might expect simply setting the language code would be sufficient and a default country code would be selected by default but there seem to parts of the system which can't deal with this. I saw the problem when setting the LANG environment variable and glibc's locale function failed to work correctly. Not sure if the same problem would exist in GNU gettext when selecting the message catalog, but why take the chance?

This covers the doc string
>From 48b4e658733d9dcdac9946414b710fe99a0637dd Mon Sep 17 00:00:00 2001
From: Adam Young <ayo...@redhat.com>
Date: Mon, 20 Sep 2010 10:46:39 -0400
Subject: [PATCH] Locale for language
 Corrected the doc string to signify that the language field is the local used to for translation.

 ipalib/plugins/internal.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py
index 3a0178d..9a7137d 100644
--- a/ipalib/plugins/internal.py
+++ b/ipalib/plugins/internal.py
@@ -79,7 +79,7 @@ class plugin_metadata(Command):
     takes_options = (
-            doc=_('Two Letter Code for  Language Translation'),
+            doc=_('Locale used for Translation, in Posix form.  Example:  Australian English is en_AU'),

Freeipa-devel mailing list

Reply via email to