Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
[Freeciv-Dev] Re: on translating "Game"
Home

[Freeciv-Dev] Re: on translating "Game"

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: on translating "Game"
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Wed, 29 Sep 1999 11:37:20 -0400

At 1999/09/28 23:10 , David Pfitzner wrote:
>Jules Bean wrote:
>
>> > So I think word 'game' would be generally perfect for this resource,
>> > except problem with translation.
>> 
>> I thought we solved that problem in another thread.  Something like
>> __("resource:game") and __("menu:game") to distinguish the two?
>
>Yes, that is my preference, for some implementation of __().
>
>One small complication is that both instances of "Game" occur 
>as generic data (in rulesets, data/Freeciv, N_() in code)
>which are then translated by _() en-masse along with lots
>of other such data stringa.  
>
>This means __() would have to be used on _all_ such data in the
>same contexts, which means __() *must* work properly for strings 
>without ':', and also means none of the other strings so processed 
>are allowed to include a ':' character (that is, other than for 
>the above meaning).  (Or would have to have an artificial leading 
>':'.)
>
>Off-hand I can't think of any specific problems which include 
>a "literal" ':', but we may want to consider if some other 
>character(s) than ':' are less likely to have this problem...
>(Although ':' does have the advantage of conveying roughly 
>what we mean in this usage.)

Perhaps, we could use a leading character to signal when to do the search
for the separator.  That way, only the first character is restricted, and
the macro is fairly straight-forward:

#define __(s) ((*(s) == '?') ? (strchr(_(s), ':') + 1) : _(s))

We could use any character we think is "unimportant" for the introducer
('?' in the above example), and still use colon for the separator.  Also, I
believe the above even protects against the translator forgetting to
prepend the introducer (but, not against forgetting the separator).

Alternatively, a slight modification of the above macro (which would call
_() twice):

#define __(s) ((*(_(s)) == '?') ? (strchr(_(s), ':') + 1) : _(s))

would allow the translators to translate these qualified strings into
unqualified strings.  E.g.:

msgid "?resource:Game"
msgstr "Translation of Game"

Then, the only restriction is that translation *not* begin with the
introducer character.

jjm


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