[Sputnik-list] Translation table format

[Dado Sutter]

Hello everyone,
   Yuri, IMHO this is the best way to treat all the issues we've been
discussing here, regarding the translation mechanisms but let's here some
more opinions before you begin to change your code.
   I will begin to use pt_BR then (instead of just pt) and I will also move
your english default sentences/terms to a en_US key on the tables, so you
can work on the new code to use it.
   And yes, I confirm the translation I've sent you was for pt_BR.

Grettingssssssss
Dado

On 7/6/07, Yuri Takhteyev <yuri at sims.berkeley.edu> wrote:
>
> Yes, if string IDs will be treated as just IDs (as we discussed in an
> earlier thread), then it makes sense to treat all translations
> equally.  So, each table will look something like this:
>
>     EDIT = {
>        en = "Edit",
>        ru = "Редактировать",
>        pt = "Editar",
>     }
>
> The similarity between "EDIT" (the variable name) and "Edit" (the
> value for "en"), will be treated as just a coincidence.  All
> translations will need to be specified explicitly.
>
> > If the default language really needs to be taken from the locale table
> (and
> > not from a config option elsewhere), something like the following syntax
> > might be better:
>
> I think the the default language should be identified by its standard
> code in each table, but there should be a variable in the file that
> specifies either the default language or the order of languages to
> try.  I.e., either:
>
>     DEFAULT_LANGUAGE = "en"
>
> or
>
>     LANGUAGE_ORDER = {"en", "es", "pt", "ru"}
>
> > We might also change the Brazilian Portuguese locale Key to br, instead
> of
> > pt, to distinguish from an eventual future Portugal / African
> Portuguese.
>
> Actually, what I wanted to do is the following: Each language should
> be identified by its two letter or three letter code (see
> http://www.iana.org/assignments/language-subtag-registry).  In case of
> Portuguese, its "pt" for either European, Brazilian or Caboverdian
> Portuguese.  More specific varieties of each language would be
> identified by subtags, which could be regional or other, using IANA
> subtags when possible, e.g. "pt_BR", "pt_CV", "en_GB" (British),
> "es_AR", etc.  The code that does the translation will check both.
> I.e., if the "pt_BR" interface is chose, then pt_BR value will be used
> if defined, if not, we'll use "pt" and if not, then en.   Note that if
> we only got one Portuguese translation, we should label it "pt".  Same
> with English.  We can start with
>
>     HI_USER {
>        en = "Hi, $user!"
>     }
>
> Then move to
>
>     HI_USER = {
>        en = "Hi, $user!",
>        en_GB = "How do you do, $user?",
>        en_AU = "G'day, $user!"
>     }
>
> Note that with this approach one only need to "translate" into
> specific varieties of English or Portuguese only those strings that
> actually need to be different.  E.g., we can just have
>
>     LOGIN = {
>        en = "Login"
>     }
>
> rather than:
>
>     LOGIN = {
>        en_US = "Login",
>        en_GB = "Login",
>        en_AU = "Login"
>     }
>
> This basically means following RFC 4646
> (http://www.rfc-editor.org/rfc/rfc4646.txt) when possible, with the
> only exception of using underscores instead of hyphens as dividors, to
> make it easier to write this in Lua.
>
> > I have finished the first pass on the (portuguese) translation page and
> > we'll be refining it, maybe in an on-line Sputnik version (so everyone
> can
> > contribute) in the next days.
>
> You mean your pt_BR translation, right?  :)  Anyway, dado's
> translation is in SVN now.
>
> - yuri
>
> --
> http://www.freewisdom.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.luaforge.net/pipermail/sputnik-list/attachments/20070706/e3b085fb/attachment.html