 | | | | | | |
| |
|
Willy Tschager wrote:
> could you please work out a standard for the
> internationalization of the part names.
I don't think it is really the task of the LSC to define a
standard for internationalization (i18n) of part names, but
here is a sketch of how I believe it should be handled:
+ The names found in LDraw files (parts and models) are
considered to be in the "POSIX" locale.
+ LDraw.org publishes a ".pot" file (translation template)
containing the names of all the parts files available
from LDraw.org (both official and unofficial).
+ Translators can submit translations (as ".po" files) back
to LDraw.org for distribution to users and developers.
+ Developers of applications using the LDraw.org parts
library are encouraged to use the translations of the
parts names available from LDraw.org to make the parts
names available to the users in their preferred
languages.
Putting the translations in the parts files would mean that
the parts library would have to be updated, every time
somebody added a translation of the name of a part to one
more language.
Using the (GNU) Gettext approach of keeping translations in
separate files is in my opinion preferable.
Jacob
--
»But you have to be a bit wary of a ship that collects
snowflakes.« -- Diziet Sma
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> Willy Tschager wrote:
>
> > could you please work out a standard for the
> > internationalization of the part names.
>
> I don't think it is really the task of the LSC to define a
> standard for internationalization (i18n) of part names
I feel it falls more to the LSC than any other group currently in existence.
Although, the SteerCo could appoint a new i18n group...
> here is a sketch of how I believe it should be handled:
>
> + The names found in LDraw files (parts and models) are
> considered to be in the "POSIX" locale.
>
> + LDraw.org publishes a ".pot" file (translation template)
> containing the names of all the parts files available
> from LDraw.org (both official and unofficial).
>
> + Translators can submit translations (as ".po" files) back
> to LDraw.org for distribution to users and developers.
>
> + Developers of applications using the LDraw.org parts
> library are encouraged to use the translations of the
> parts names available from LDraw.org to make the parts
> names available to the users in their preferred
> languages.
I am picking my way through
http://www.gnu.org/software/gettext/manual/html_node/gettext.html
Is there another source of a good summary?
From what I've read, this approach doesn't quite fit our needs, but would be
useable. That is, we've got a good key (the part number) to use as a basis for
looking up translations, but gettext uses the original part title.
> Putting the translations in the parts files would mean that
> the parts library would have to be updated, every time
> somebody added a translation of the name of a part to one
> more language.
Nod, true.
> Using the (GNU) Gettext approach of keeping translations in
> separate files is in my opinion preferable.
I agree.
Steve
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> > Willy Tschager wrote:
> >
> > > could you please work out a standard for the
> > > internationalization of the part names.
> >
> > I don't think it is really the task of the LSC to define a
> > standard for internationalization (i18n) of part names
>
> I feel it falls more to the LSC than any other group currently in existence.
> Although, the SteerCo could appoint a new i18n group...
Personally I think this is well within the pervue of the LSC. I see no need for
another organization.
Kevin
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Kevin L. Clague wrote:
> In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> > In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> > > Willy Tschager wrote:
> > >
> > > > could you please work out a standard for the
> > > > internationalization of the part names.
> > >
> > > I don't think it is really the task of the LSC to define a
> > > standard for internationalization (i18n) of part names
> >
> > I feel it falls more to the LSC than any other group currently in existence.
> > Although, the SteerCo could appoint a new i18n group...
>
> Personally I think this is well within the pervue of the LSC. I see no need for
> another organization.
Personally, I agree. That said, if the LSC decided that internationalization is
not a goal then some consideration of how to proceed would be needed, but I
would tend to want to follow their recommendation, it's their charter to own
decisions like this about standards directions. If the LSC decided i18n was
good, but that they did NOT want to tackle this and wanted to see another
committee formed, I guess I'd want to understand why, but would support that
decision as well, once I understood it.
| | | | | | | | | | | | | | | | |
Larry Pieniazek wrote:
> In lugnet.cad.dev.org.ldraw, Kevin L. Clague wrote:
> > In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> > > > Willy Tschager wrote:
> > > > > could you please work out a standard for the
> > > > > internationalization of the part names.
> > > I feel it falls more to the LSC than any other group
> > > currently in existence. Although, the SteerCo could
> > > appoint a new i18n group...
> > Personally I think this is well within the pervue of the
> > LSC. I see no need for another organization.
>
> Personally, I agree.
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.
Play well,
Jacob
--
Noir comme le diable
Chaud comme l'enfer
Pur comme un ange,
Doux comme l'amour.
| | | | | | | | | | | | | | | | | |
| |
|
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!
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.
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? (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 lugnet.cad.dev.org.ldraw, 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!
>
> 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.
>
> 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? (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)
From a technical perspective I agree with Larry that the part number looks like
the best key, and that the current part name is just one instance of an
international language set of names.
If we percieve peeron and and bricklink as countries, then we could also solve
the translation table lookup from LDraw to peeron (is there really an issue
here? I forget), or bricklink. Furthermore we should also be able to do the
reverse from bricklink to LDraw. Maybe even LDraw to LEGO for the part types we
know about.
Kevin
| | | | | | | | | | | | | | | | | | | | |
On Tue, Mar 01, 2005 at 04:35:15PM +0000, Kevin L. Clague wrote:
> If we percieve peeron and and bricklink as countries, then we could
> also solve the translation table lookup from LDraw to peeron (is there
> really an issue here? I forget), or bricklink. Furthermore we should
> also be able to do the reverse from bricklink to LDraw. Maybe even
> LDraw to LEGO for the part types we know about.
Peeron/LDraw/Partsref <-> BL isn't simple, because the part numbers are
NOT consistant. AFAIK, the only way to actually resolve that is to
build a proper translation table, which is what I think BrikTrak uses.
--
Dan Boger
dan@peeron.com
| | | | | | | | | | | | | | | | | | | | |
| |
|
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!"
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> In general, part numbers change, while part names are
> constant.
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 head.
Sorry. Have to disagree. Parts names change far more frequently than known
numbers, after all known numbers are printed on the parts.
However, X numbers and pattern variations are far more fluid
William
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, William Howard wrote:
> In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> > In general, part numbers change, while part names are
> > constant.
>
> Mmmmm!!!
>
> Rock pieces (BURPs, LURPs, et al) recently became panels ...
> Castle walls also are in the process of becomming panels ...
If only we knew what to do with that lousy crenellated wall topper, we could get
rid of the Castle group altogether...
> I no longer know where Boat Stud is as it moves so often ...
FYI: the Boat Stud is now Dish 2 x 2 -- both Peeron and LDList will still match
on Boat Stud. And it was officially renamed only 1 time, in 2004-02. It just
took us a few unofficial gyrations to figure out the better name. :)
> And that's just the first three off the top of my head.
You didn't mention pattern descriptions, which get tweaked at the drop of a hat.
It seems like half the parts that are submitted to the PT for updates have a
title/name change. Many of which get changed back before the part is released.
> Sorry. Have to disagree. Parts names change far more frequently than known
> numbers, after all known numbers are printed on the parts.
And if we change a part number, we almost always leave a "Moved to" stub file.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> In lugnet.cad.dev.org.ldraw, William Howard wrote:
> > I no longer know where Boat Stud is as it moves so often ...
> FYI: the Boat Stud is now Dish 2 x 2
> And it was officially renamed only 1 time, in 2004-02.
OK, so I exaggerated a little bit. ;-) Only reason it sticks in my mind is
because of that one release where it and the 2x2 radar dish shared the same
name.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> In lugnet.cad.dev.org.ldraw, William Howard wrote:
> > In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> > > In general, part numbers change, while part names are
> > > constant.
> >
> > Mmmmm!!!
> >
> > Rock pieces (BURPs, LURPs, et al) recently became panels ...
> > Castle walls also are in the process of becomming panels ...
>
> If only we knew what to do with that lousy crenellated wall topper, we could get
> rid of the Castle group altogether...
They're just modified plate & brick:
6072 Plate 7 x 7 with cutouts and castle crenelations
6066 Brick 4 x 8 x 2 & 1/3 with cutouts and castle crenalations
-John Van
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, John VanZwieten wrote:
> In lugnet.cad.dev.org.ldraw, Steve Bliss wrote:
> > If only we knew what to do with that lousy crenellated wall topper, we could get
> > rid of the Castle group altogether...
>
> They're just modified plate & brick:
> 6072 Plate 7 x 7 with cutouts and castle crenelations
> 6066 Brick 4 x 8 x 2 & 1/3 with cutouts and castle crenalations
Well, yeah. I guess so. I feel like they're *way* pushing the "brick with
modification" envelope.
OTOH, your suggestions are definitely better than leaving those two parts as the
only "Castle" parts.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, William Howard wrote:
> In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> > In general, part numbers change, while part names are
> > constant.
>
> 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 head.
Devil's advocate for a sec, were those NAME changes or CATEGORY changes?
> Sorry. Have to disagree. Parts names change far more frequently than known
> numbers, after all known numbers are printed on the parts.
That was my thinking too, but I have no stats to back it up.
> However, X numbers and pattern variations are far more fluid
To Jacob's point about keeping changes in sync, which I agree is a valid concern
and would need to be addressed: If the translation file ships as part of a part
update, then I would think that any time a part number changes, so does the
translation file, which means that when you install an update you are in sync
(that may not be true if you live on the bleeding edge with unreleased parts and
etc, but if you only update when stuff is officially released wouldn't you be
OK?).
| | | | | | | | | | | | | | | | | | | | | | | |
Larry Pieniazek wrote:
> > In lugnet.cad.dev.org.ldraw, Jacob Sparre Andersen wrote:
> > > In general, part numbers change, while part names are
> > > constant.
Apparently my impression wasn't quite correct here.
> To Jacob's point about keeping changes in sync, which I
> agree is a valid concern and would need to be addressed:
> If the translation file ships as part of a part update,
> then I would think that any time a part number changes, so
> does the translation file, which means that when you
> install an update you are in sync
Yes. But that would require the programs to be able to work
directly on whatever translation format we decide to use.
And it would inflate the parts library updates with
approximately 120 kb/language (25 kb/language with sensible
compression).
Play well,
Jacob
--
"Hungh. You see! More bear. Yellow snow is always dead give-away."
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Larry Pieniazek wrote:
> In lugnet.cad.dev.org.ldraw, William Howard wrote:
> > 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 head.
>
> Devil's advocate for a sec, were those NAME changes or CATEGORY changes?
Both. The default for CATEGORY is the first word from the part title. Most
parts have no explicit CATEGORY. I believe in all the examples given by
William, the default CATEGORY is in effect.
> To Jacob's point about keeping changes in sync, which I agree is a valid concern
> and would need to be addressed: If the translation file ships as part of a part
> update, then I would think that any time a part number changes, so does the
> translation file, which means that when you install an update you are in sync
> (that may not be true if you live on the bleeding edge with unreleased parts and
> etc, but if you only update when stuff is officially released wouldn't you be
> OK?).
I expect we'd work on updating translations in parallel with part development.
Otherwise, we'd be adding a big 'translation step' to every parts update, which
would only slow things down even more than they already are.
More specifically, I expect that updates to any one translation (ie, one
language) would come in batches, because translators would probably rather
handle them that way, rather than translating each individual part as it comes
by.
Steve
| | | | | | | | | | | | | | | | | | | | |
| |
|
Larry Pieniazek wrote:
>
> 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.
But the existing part names are the unique identifier *we* have control
over. Lego may well start calling a 'Brick 2x2' 'OleKirk347' in the next
version of the moulds, but it's still a 'Brick 2x2', right?
There's also the value of at least a default text when the translation file
is older than the part library.
> do names change as often as part numbers do?
No idea.
> are they the right key from a theoretical standpoint?
Too theoretical.
> part numbers are designed to be unambiguous,
As unambigous as set numbers? Why do you trust Lego not to reuse the number
of an old part that they will *never* produce again?
> names are not necessarily so, although usually are
The names are ours. We can make the totally unambigous if we need to.
--
Anders Isaksson, Sweden
BlockCAD: http://w1.161.telia.com/~u16122508/proglego.htm
Gallery: http://w1.161.telia.com/~u16122508/gallery/index.htm
| | | | | | | | | | | | | | | | | | | | | |
Anders Isaksson wrote:
> Larry Pieniazek wrote:
> But the existing part names are the unique identifier *we*
> have control over.
Exactly.
> There's also the value of at least a default text when the
> translation file is older than the part library.
Yes.
> > part numbers are designed to be unambiguous,
>
> As unambigous as set numbers? Why do you trust Lego not to
> reuse the number of an old part that they will *never*
> produce again?
I wouldn't. But we would have to work around that problem
anyway.
> The names are ours. We can make the totally unambigous if
> we need to.
Exactly.
Play well,
Jacob
--
»Men I må godt være smukke imens
vi falder for jeres intelligens.«
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Anders Isaksson wrote:
> Larry Pieniazek wrote:
> >
> > 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.
>
> But the existing part names are the unique identifier *we* have control
> over. Lego may well start calling a 'Brick 2x2' 'OleKirk347' in the next
> version of the moulds, but it's still a 'Brick 2x2', right?
And Lego may change the number of that 2x2 from 3003 to 53456343, but it'd still
be a 3003 to us, right?
> There's also the value of at least a default text when the translation file
> is older than the part library.
Yes, true.
> > part numbers are designed to be unambiguous,
>
> As unambigous as set numbers? Why do you trust Lego not to reuse the number
> of an old part that they will *never* produce again?
LDraw numbers are designed to be unambiguous. And that unambiguity is enforced
by the fact that we store our data in the file system -- so there's no way for
two different LDraw parts to have the same number (well, not at the same time).
Steve
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, 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!
>
> 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.
a. I don't think gettext prevents you from using message codes in your code, it
just allows you to use whatever text you want.
b. Allowing embedded messages makes it easier for programmers, because they can
read what's being output.
c. Allowing embedded messages makes it easier for translators, because they can
see the text they need to translate, without having to cross-reference a message
code.
however...
d. Allowing embedded messages will tempt programmers (and we all know one or
more programmers of easy virtue) to tweak the inline verbiage, causing
turbulence in the translation process pipeline.
> 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? (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 a 'solution vacuum', I totally agree with you. A solution that we build
ourselves would almost certainly be driven by part number/filename. They are
inherently unique; they change less often than part titles; if one changes,
there's usually a forwarding pointer.
But if there's a reasonably common standard that would allow others to leverage
our efforts, it would possibly be a good thing for us to make use of that
standard.
Steve
| | | | | | |
