To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.dev.org.ldrawOpen lugnet.cad.dev.org.ldraw in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / Organizations / LDraw / 3483
3482  |  3484
Subject: 
Re: Internationalization of the part library?
Newsgroups: 
lugnet.cad.dev.org.ldraw
Date: 
Tue, 1 Mar 2005 16:41:12 GMT
Viewed: 
1613 times
  
Larry Pieniazek wrote:
In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:

It seems like there is general agreement that it would
be a good idea, if the LSC creates a standard for i18n
in LDraw parts names, so I will post a proposal to the
LSC ASAP.

Thanks! Looking forward to it!

Done. :-)  (now we just have to see what the rest of the LSC says to it)

I sort of don't follow the subtlety of the issue with
lookup (GNU gettext?), but it seems to me from the outside
that the part number ought to be the lookup key rather
than one version of the part name. At least, when I've
done i18n stuff in my real job, (NLS, (National Language
Support) we called it) we always had a code that was then
replaced by a returned lookup value depending on the local
language.

I have worked both with code-based and with string-based
lookup (not professionally, though) the last ten-fifteen
years.  Both methods have their benefits and drawbacks, but
for distributed projects, using an actual string which can
act as a fall-back, is the winner (IMO).

It is harder to make the keys sufficiently unique, when you
use strings, but the built-in fall-back, the easy
reusability of the translations, the easy access to a
reference string when you are working on a translation and
the simplicity of supporting multiple versions of a program
with one translation file (without having to worry if keys
have completely different meanings in the different
versions)

The parts files already have "one" replacement value in
them, the text form of the part name, but that's not a
good choice necessarily for an unambiguous key, nor is it
as stable as the part number itself, right?

Wrong (AFAICS)

(or is it...
do names change as often as part numbers do? and even if
they do not, are they the right key from a theoretical
standpoint? part numbers are designed to be unambiguous,
names are not necessarily so, although usually are)

In general, part numbers change, while part names are
constant.  If we use the part numbers as the keys, we have
the problem of making sure that users update their
translation databases at the same time as they update their
parts libraries.  If we use the part names, the worst thing
the users will run into is a part name in English (if they
update their parts library before their translation
database).

Play well,

Jacob
--
Adlai Stevenson said it all when, at an event during the
1956 Presidential campaign, a woman shouted, "You have the
vote of every thinking person!" Stevenson shouted back,
"That's not enough, madam, we need a majority!"



Message has 1 Reply:
  Re: Internationalization of the part library?
 
(...) Mmmmm!!! Rock pieces (BURPs, LURPs, et al) recently became panels ... Castle walls also are in the process of becomming panels ... I no longer know where Boat Stud is as it moves so often ... And that's just the first three off the top of my (...) (19 years ago, 1-Mar-05, to lugnet.cad.dev.org.ldraw)

Message is in Reply To:
  Re: Internationalization of the part library?
 
(...) Thanks! Looking forward to it! I sort of don't follow the subtlety of the issue with lookup (GNU gettext?), but it seems to me from the outside that the part number ought to be the lookup key rather than one version of the part name. At least, (...) (19 years ago, 1-Mar-05, to lugnet.cad.dev.org.ldraw)

22 Messages in This Thread:








Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR