[Freeciv-Dev] Re: Improved grammatic handling of nation names.

[Jeff Mallatt <jjm@xxxxxxxxxxxx>]

At 2000/09/03 10:39 , Gerhard Killesreiter wrote:
>On Sat, 2 Sep 2000, Jeff Mallatt wrote:
>> Do you have a suggestion for how a more general approach would work?
>
>umm, I am by no means a coder. However, I did post the following
>suggestion some time ago. I did not get any response, so probably it is
>silly, but I would like to know why :)
>
>   I propose the inclusion of additional fields in the
>   <nation>.rulesets files, i.e. making the nation's name an array to 
>   be filled with the cases in singular und plural.
>   Do the C-stringhandling functions accept arrays of strings?
>   Apparently not. Is it possible to write some modified printf?
>
>The printing of a string would then look like
>
>The %a[i,j] did something to the %a[k,l].
>
>Where the indices i,j,k,l could be freely chosen by the translator.

Something like this could be made to work (it may be lots of work, however ;).

Two dimensions might be a problem, in general.  The ruleset files might
contain a single "namelist", that would be translated, e.g.:

  name="German"
  namelist=_("German|Germans|Germans'|A German|a German\
  |A German's|a German's|The German|the German\
  |The German's|the German's|The Germans|the Germans\
  |The Germans'|the Germans'")

And, the code would look something like:

  i18nsprintf(buffer,
              _("%a[11] did something to %a[12]."),
              get_nation_namelist(attacker->nation),
              get_nation_namelist(defender->nation));

Since the translators would have control of both parts (the name list and
the format string), this would be most general -- a translator could even
add cases that exist only in their language.

On the down side, this is fairly hard to maintain.  The order and length of
the list must be maintained consistantly across all the nations files.
Futhermore, inserting an element anywhere other than at the end would
require changing most/all format statements.  Also, simply using this is
prone to errors -- I had to count three times to get the indices (11 and
12) correct for my example.

jjm