Re: [Freeciv-Dev] [Freeciv-i18n] "negated" support in helpdata.c

2013-04-07 Thread Marko Lindqvist
On 7 April 2013 18:09, Bernd Jendrissek  wrote:

> On Sun, Apr 7, 2013 at 7:41 AM, Emmet Hikory  wrote:
> > Is there anything I can do with comments or other indicators to help
> > indicate to translators that the paired strings are intended to be
> negated
> > representations of each other, or is all this lost when the strings are
> > extracted for translation?
>
> All the gettext documentation I can find notes that comments to
> translators are introduced as
>
> /* TRANSLATORS:
>
> (with some flexibility for the comment syntax itself)
>
> But freeciv code seems to use /* TRANS: consistently (and it shows up
> in the .po files).
>


Wiki pages related to translations

Main page:
http://freeciv.wikia.com/wiki/Translations

Coder's view:
http://freeciv.wikia.com/wiki/Internationalization


 - ML
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] [Freeciv-i18n] "negated" support in helpdata.c

2013-04-07 Thread Bernd Jendrissek
On Sun, Apr 7, 2013 at 7:41 AM, Emmet Hikory  wrote:
> Is there anything I can do with comments or other indicators to help
> indicate to translators that the paired strings are intended to be negated
> representations of each other, or is all this lost when the strings are
> extracted for translation?

All the gettext documentation I can find notes that comments to
translators are introduced as

/* TRANSLATORS:

(with some flexibility for the comment syntax itself)

But freeciv code seems to use /* TRANS: consistently (and it shows up
in the .po files).

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] [Freeciv-i18n] "negated" support in helpdata.c

2013-04-06 Thread Emmet Hikory
On Sat, Apr 06, 2013 Hubert Kowalewski wrote:
> 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.

Thanks a lot.  In that case, I'll do it with two separate translatable
strings for each condition.  This gives maximum freedom and flexibility.

Something like:

  if (!preq->negated) {
cat_snprintf(buf, bufsz,
 _("Requires that any player has researched "
   "the %s technology.\n"),
 advance_name_for_player(pplayer, advance_number
 (preq->source.value.advance)));
  } else {
cat_snprintf(buf, bufsz,
 _("Requires that no player has yet researched "
   "the %s technology.\n"),
 advance_name_for_player(pplayer, advance_number
 (preq->source.value.advance)));
  }
return TRUE;

So translators will have two strings to work with, allowing words in
the target language to be inserted wherever needed for the grammar of the
target language (example for English above uses "any" and "no...yet" as
a demonstration).  This also allows more extreme differentiation in the
case where direct negation is difficult in a target language, such as:

  if (!preq->negated) {
cat_snprintf(buf, bufsz, _("Requires the %s goverment.\n"),
 government_name_translation(preq->source.value.govern));
  } else {
cat_snprintf(buf, bufsz, _("Not available under the %s government.\n").
 government_name_translation(preq->source.value.govern));
  }
  return TRUE;

Is there anything I can do with comments or other indicators to help
indicate to translators that the paired strings are intended to be negated
representations of each other, or is all this lost when the strings are
extracted for translation?

-- 
Emmet HIKORY

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] [Freeciv-i18n] "negated" support in helpdata.c

2013-04-06 Thread Hubert Kowalewski
Hi,

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.

Hubert


On 5 April 2013 22:07, Marko Lindqvist  wrote:

> Adding i18n list as this is mainly concern for translations.
>
>
> On 5 April 2013 20:19, Emmet Hikory  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
>
>


-- 
Hubert
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev