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
>> already there led to patch #3836, but I stumbled when it came to adding
>> 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
>> depending on whether this is a positive or negative requirement. Decide
>> to use with preq->negated : _("First String") ? _("Second String")
>> 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
>> Emmet HIKORY
> - ML
> Freeciv-i18n mailing list
Freeciv-dev mailing list