Follow-up Comment #8, patch #4190 (project freeciv):

Here's various points that come to my mind after reading your comment. I need
to think overall picture a bit longer - but I'm inclined to continue with my
current patchset for now. We can improve it later, but I want working system
relative soon (in terms of our releases: I want it to S2_5) I try to keep
doors open to multiple directions as long as possible, however, when
implementing the patchset.

- I had already discarded the idea of reusing group definiton "Core" for
marking translation domain, on the basis that custom ruleset may add new
nations to their "Core" group and such a ruleset should not expect to find
translations from core domain.
- From what I've thought of so far, I prefer adding "translation_domain =
"freeciv"" to core nations. Other nations would default to using extended
nations domain. We've already established that there should not be much
changes on what nations belongs to core group, so there would be no much
maintenance work. Also, this would be rather clean ruleset format to add
localization support for custom rulesets, which feature I'm now considering
quite seriously to implement
- Opposite to your example, Sini has told me that splitting the translations
would make improvements to Finnish translation much more likely - she has no
time to work on massive full .po, but provided more compact core .po she could
update that part (and leave extended nations untranslated)
- Purpose of "R_()" is not collection of translatable strings (that happens
based on "_(" -part of it, and dictates that we can't have more namespace
clean naming like "_R()", "PL_R()". "R_()" is meant for runtime fetching of
translations from correct domain as default domain for freeciv-ruledit too
will be freeciv core (for all the code shared with freeciv server to get
correct translations)
- We already use multiple domains though in a less obvious way. The libraries
we use have translations of their own, most obvious example being gtk+ stock
buttons.
- When I generated extended set .po -files by msgmerging full .po against
their .pot, I noticed how the files were about same size as the originals. I
have not checked them, but I assume this to be due to the fact that even when
.pot lacks the string existing in .po, it's not removed but merely commented
out. That's not a big problem, but speaks against doing the conversion
repeatedly (i.e. getting all the obsolete messages back in even if they have
once been removed)

    _______________________________________________________

Reply to this item at:

  <http://gna.org/patch/?4190>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


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

Reply via email to