[LSC] Internationalisation (I18N) of the part library

[Travis Cobbs]

On 9/30/06, William Howard <william at howard-family.fsworld.co.uk> wrote:
>
> >From the laundry list
>
> > 2.) Internationalisation (I18N) of the part library
> > http://news.lugnet.com/cad/dev/org/ldraw/?n=3470
> > http://news.lugnet.com/cad/dev/?n=10420
> > http://five.pairlist.net/pipermail/lsc/2005-March/000335.html
> > http://five.pairlist.net/pipermail/lsc/2005-April/000339.html
>
> Before even contemplating HOW we are going to I18N the library I think we
> need to decide
>
> a) WHAT is going to be covered by I18N
> b) what KEY we are going to use
>
>
> My thoughts on a) are
>   i) part name/description
> ii) category
> iii) keywords
>
> Everything else in the header should be Australian English, while comments
> within the file can be any language.
>
>
> While b) is somewhat harder to decided.  Both the part number and part
> description/name are candidates.  Both can change.  Both do change.  Both
> have issues.  As a programmer the uniqueness of the part number is
> appealing.  As files are stored on disk, there can never be two parts with
> the same number, but there can (and have - the boat stud for example) been
> two parts with the same name.
>
>
> _______________________________________________
> LSC mailing list
> LSC at ldraw.org
> http://five.pairlist.net/mailman/listinfo/lsc
>



In response to to the above, here's my thinking:

Have one table with filename as the primary key that includes a sub-key
description.  I don't think we need name, because that's just the filename.
Is there ever a need to translate that?
Have another table which is a simple string lookup to be used for categories
and keywords.  The primary key of this table is the English text found in
the files (space allowed), and the data is the translation.

By "table", I mean something that's logically equivalent to a database
table.  This means that whatever file format we use needs to support at
least two levels, and maybe three (plus the actual data):

Table
Primary Key
Sub Key

The Sub Key level isn't necessary if we don't want to leave open the
possibility of having unique translations for any fields other than the
description.  It's probably a good idea to have it there, though.  XML would
obviously work fine.

We could fairly easily create a tool that scans the entire parts library and
generates an English version of the translation file.  Translators would
then just go through that file and translate the data.

--Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://five.pairlist.net/pipermail/lsc/attachments/20061006/06452707/attachment.html