discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Localize GWorkspace


From: Nicola Pero
Subject: Re: Localize GWorkspace
Date: Fri, 31 Aug 2001 11:04:12 +0100 (BST)

>     NP> The
>     NP> comment can help the translator to decide how to translate
>     NP> when it is not clear how to translate (because the original
>     NP> string is now out of context, and out of context might not be
>     NP> so clear what the string means).  The comment is totally
>     NP> ignored by the library code (which means that because we don't
>     NP> have the tools now, the comment is totally ignored for now :-)
>     NP> ).
> 
> I remember a similar thread years ago, where we talked about using the
> comment itself as a "subkey" to be able to find the right translation:
> you can have more than one place where the same english string is
> used, but each of them may require a different national
> translation. This is currently a limitation of the gettext library...

Hmm ... yes, you can have a `subkey', but it is a different thing than the
comment ... the comment is really ignored ... but yes because NSBundle
supports tables, you can get a result similar to what you describe - that
is, having the same English string being translated in different ways when
it appears in different locations - and you get it by using different
tables - NSBundle allows you to have multiple tables - in the default
usage, everything is configured for the simplest and most straightforward
way of doing it, so you have a single table - stored in the
Localizable.strings file - but if you want, you can look up strings for
translations in arbitrary tables.  You would have different files
containing different tables.  When you look up a string for translation,
you might either leave the table unspecified, in which case
Localizable.strings is used (this is what is normally done), or specify a
specific table (different from Localizable.strings) and that table is used
instead (resulting in a different translation of the string).  To specify
a different table for translation, you use 

NSLocalizedStringFromTable (@"Show All", /* key */ 
                            @"Window Menu",     /* table */
                            @"Menu option to show all open windows"); 
                            /* comment */

That could get a different translation than 

NSLocalizedStringFromTable (@"Show All",  /* key */
                            @"Game Actions Menu",  /* table */
                            @"Menu option to show all your troops");
                            /* comment */

because they are in different tables (sorry for the poor example).  The
comment instead is just for the human doing the translation and makes no
difference to the way the strings are looked up by the library.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]