Follow-up Comment #4, patch #4400 (project freeciv):
> S2_4 would benefit from it [...] Probably only worth it if
> there is vast player outcry about the help being subtly wrong.
Indeed, and reviewing the diffs, it doesn't make significant improvement with
common rulesets (unlike patch #3841).
> "surviving or non-wonder continent-ranged requirements not
> supported": is the survival part not a yet-unimplemented part
> of the sources cache, or is this intended for some reason?
I don't think it's deliberately left out. Supported surviving requirements
seem to generally be those that were trivial to implement (world wonders and
player buildings are simple arrays indexed by improvement ID).
(Anyway, I'm not sure how a surviving continent-ranged requirement would work,
given that continents can change due to terrain change.)
> "Requires Airbase on the tile" feels like it dropped an
> article
[...]
> Also, I think [VUT_STYLE] could benefit from an article in
> many cases (at least for "Asian" and "Classical").
Articles are tricky -- even in English, we can't get "a/an" to agree with a
ruleset item. So I avoid them.
Fixing this sort of thing properly would require a much more exciting i18n
system than the one we have, much more tied into the rulesets; I don't have
effort to design such a thing and I'm not aware of an off-the-shelf design
with a well-supported workflow that we can integrate.
So, I generally punt on this; the fact that ruleset items are capitalised
means I can pretend they're proper nouns, removing articles and thus defeating
English's epenthesis at the cost of sounding slightly awkward (but still
better than "a Airbase" or "an Fort").
(Well, this works in my head -- hopefully that's not just due to a lifetime of
exposure to badly-localised computer programs.)
Actual inflected languages presumably have it much worse; this is one reason
I'm putting in "?extra:" type qualification, to allow translators to use
different language hacks around this for each kind of ruleset object.
(...all of which means my S2_5 patch needs rework, because forgetting this
argument, I did include articles for road/base requirements in that version.)
> (yes, this is a problem with English: most languages either
> always or never have articles).
Oh good; that hopefully reduces the l10n impact of us merging continuous
("Irrigation") and discrete ("Airbase") things into the single category of
'extras'.
> "...playing the %s nation": should this be "...playing as the %s nation"?
[...]
> is the "nation" semantically useful here?
I'll think about this.
> VUT_STYLE/*: With the change in how city styles work, is
> is this the correct set of ranges? [...]
Possibly not, but I'm trying not to accrue any more yaks; my aim right now is
to get the strings matching the code capabilities.
> VUT_DIPLREL/*: These read awkwardly to me [...]
Me too, but I have no better ideas either.
> uses of PL_(): To confirm, these duplicate lines are
> to support multiple pluralisations? What about languages
> with dual number [...]?
Yes, this is for pluralisation. gettext has a standard approach to this to
accommodate different pluralisation rules; see here
<http://www.gnu.org/software/gettext/manual/gettext.html#Translating-plural-forms>.
> VUT_TERRAINALTER: Can this be safely removed [...]
See above re yaks. That said, the sentence construction is pretty ugly (with
elements like "CanRoad"), so it would be nice to remove it from that point of
view. (Note to self: this area has regressed grammatically since S2_5, I
think?)
(I suspect removing this would complicate rulesets by requiring authors to
multiply out effects-allowing-irrigation and effects-of-irrigation.)
> VUT_AI_LEVEL: Could this be "Applies to %s AI
> players" and "Does not apply to %s AI players"?
Mm, maybe -- I suppose current AI levels are adjectival and likely to stay
that way.
> VUT_MINYEAR: Perhaps "...the game has/has not yet
> reached the year..."?
That is a bit less awkward, yes.
> requirements.c:
> VUT_MAXTILEUNITS: Why use a non-verbal construction here
> (especially with a verbal hint to translators)?
For me the overriding requirement of universal_name_translation() is that it
be short, because of its use in list constructions like 'Allows Hermitage
(with Mountains, "Loner" tech, <=2 units)'. So the existing string was too
verbose for me.
(Note to self: there is more work to be done in universal_name_translation()
on S2_5.)
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?4400>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
