Update of patch #2077 (project freeciv):
Planned Release: => 2.3.0
_______________________________________________________
Follow-up Comment #8:
> It may depends of the localization for client side...
Indeed. There can be no check in server/ruleset.c that will catch the case
where two localised strings on the client are the same, if the client uses a
different locale to the server. So the check in load_nation_names() isn't
perfect, but its flaws don't make it useless, either.
There's an argument that there are less likely to be duplicate strings in
localisations provided that the English keys are distinct, as every localised
string in a localisation is likely to have gone through a single translator's
head, whereas the original nation files come from a wide range of
contributors.
(Plus, I'm nervous about adding any check on _localised_ strings that results
in a fatal error, as we could easily miss it during pre-release testing,
because we don't test every single locale for every single release, so we
could release with some locale-specific fatal error. I don't know of anywhere
else where we do a run-time check that translated strings aren't identical?)
> At least, Qn_(untranslated_name) is never displayed to the
> user...
Well, unless they happen to have an English locale :)
I'm still reluctant to change the code to allow qualifiers to bypass the
check. I can't see any valid use for allowing two nations with identical
English strings even if differently qualified; it just seems like asking for
trouble. We have so many nations and new ones all the time, it feels like it
would be easy to accidentally re-use an adjective or noun, even without
copy-and-paste.
The check isn't perfect (as discussed above), and I acknowledge that it's
somewhat Anglocentric, but I still prefer it the way it is. So, I haven't
changed it in my latest patch (although I have added comments and made the
error messages more useful).
But if you insist, I can change it to compare the qualified strings. This
will still catch the most obvious nation-editing mistake. If someone really
wanted to make two nations with the same English name, they could, and
translators wouldn't be forced to propagate that decision. So it wouldn't be
a disaster.
Perhaps J.M. Maalderink, as nations maintainer, could give an opinion?
...
> I was talking about the configuration with NLS disabled.
Right.
> Maybe it should be the same with NLS disabled, keeping a
> pointer on _Qn(vernicular)_.
I've done that. (At a slight memory cost for !ENABLE_NLS, but I'm guessing
memory economy is not the main reason why people might turn off ENABLE_NLS.)
> Probably it should be set by names_set(), not testing every
> time we call name_translation().
I'm not sure why the tradeoff between computing _translated_ when
name(s)_set() is called, versus computing it the first time a translated
string is required, should be different whether or not ENABLE_NLS is defined.
Presumably the current decision decreases startup time at a slight, probably
lesser cost at runtime. Without some rationale, I'm reluctant to make them
different. So I've kept both cases as compute-on-first-use.
In fact, if I keep the same tradeoff, then all the ENABLE_NLS
conditionalisation in name_translation.h goes away (as Q_(ptrans->vernacular)
becomes equivalent to Qn_(ptrans->vernacular) in the !ENABLE_NLS case with no
run-time cost). Less #ifdef is good, right?
>> I did wonder about standardising the transport of
>> rule/"pretty" names over the network.
> And what is your conclusion?
That's it's more than I have time to look into at the moment :/
> I can do it if you want.
Feel free.
(file #10962)
_______________________________________________________
Additional Item Attachment:
File name: trunk-allow-ruleset-rename-bis.diff Size:80 KB
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?2077>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
