While I'm hardly an authority on the coding bit, from the point of view of
the translator the 1st method look nice. In principle, I would go for
static grammar and would not like dynamically generated sentences. If I
understand this correctly, "dynamic" sentences could more or less work for
my language (Polish), but I'm not sure if negative sentences can be easily
auto-generated in other languages, so (as a translator) I'd leave as much
freedom and flexibility to translators.


On 5 April 2013 22:07, Marko Lindqvist <cazf...@gmail.com> wrote:

> Adding i18n list as this is mainly concern for translations.
> On 5 April 2013 20:19, Emmet Hikory <per...@shipstone.jp> wrote:
>>     As part of the general coverage of "negated" I wanted to update
>> the helpdata, so that it didn't report "Requires Amphibious Elephants"
>> when in fact if one had built that road adjacent to the city, one would be
>> *unable* to build the "Miniature Aquarium" SmallWonder.  Reviewing what
>> was
>> already there led to patch #3836, but I stumbled when it came to adding
>> the
>> negation, as there were four sensible ways to do it, and I'd rather ask
>> which is preferred than just do it the wrong way and need to redo it.
>> Method 1: static grammar, static strings
>>     Define four strings in the beginning of insert_requirement(), being
>> "Requires that", "Prevented by", "Applies to", "Does not apply to" or
>> similar.  Rephrase all the helpstrings to start with one of these pairs
>> of strings, and use preq->negated : reqstring ? nreqstring or similar as
>> an additional %s parameter in the cat_snprintf() calls.
>  Those should be full format strings (with '%s' in them) so that
> translators are free to set order of words (i.e. there can be something
> *after* %s) as their target language requires. "Requires %s", "Prevented by
> %s", "Applies to %s", "Does not apply to %s".
>> Method 2: static grammer, dynamic strings
>>     Define two string variables at the beginning of insert_requirement(),
>> being "Requires that" and "Applies to".  Have a single conditional on
>> preq->negated that would reset these strings to something else if it was
>> met.  Rephrase all the helpstrings to start with one of these pairs of
>> strings, and use reqstring or appstring as an additional %s parameter.
>> Method 3: dynamic grammar, compound calls
>>     Replace the current translated strings with pairs of translated
>> strings
>> depending on whether this is a positive or negative requirement.  Decide
>> which
>> to use with preq->negated : _("First String") ? _("Second String")
>> embedded
>> in the cat_snprintf() calls.
>> Method 4: dynamic grammar, conditional calls
>>     Duplicate and wrap the snprintf() calls in preq->negated conditionals.
>> Rewrite the negative text in every case.
>>     Advice, selection, or recommendation of even better ways to do it
>> welcome.
>> --
>> Emmet HIKORY
>  - ML
> _______________________________________________
> Freeciv-i18n mailing list
> freeciv-i...@gna.org
> https://mail.gna.org/listinfo/freeciv-i18n

Freeciv-dev mailing list

Reply via email to