Follow-up Comment #7, patch #2077 (project freeciv):

> (b) to avoid two separate game entities having the same
> user-visible string, which is more arguable. That's why I'm
> comparing after stripping off the qualifier with Qn() (and it's
> more or less equivalent to the old code). Comparing with the
> qualifier included could let through two identical-to-the-user
> nations, and I'm finding it hard to think of a reason why we'd
> ever want two nations with the same English string and different
> qualifiers.

And the only string displayed to the users is name_translation() in server
side. It may depends of the localization for client side... At least,
Qn_(untranslated_name) is never displayed to the user...

>> As untranslated_name() is nearly not used and rule_name() is
>> now a field of the name_translation structure, the pointer
>> member ("translated") should be useful to keep the start of
>> the string to display to the user Qn(vernicular).
>
> I'm afraid I don't understand what you're suggesting here.

Sorry, rereading what I wrote... I agree, this is especially unclear. I was
talking about the configuration with NLS disabled. When NLS is enabled, the
member _translated_ is a pointer returned with _gettext()_ or
_Qn(vernicular)_ if the translation is missing. Then, we have very fast
access to that data. Maybe it should be the same with NLS disabled, keeping a
pointer on _Qn(vernicular)_. Probably it should be set by names_set(), not
testing every time we call name_translation().

> I did wonder about standardising the transport of
> rule/"pretty" names over the network.

And what is your conclusion? I can do it if you want.


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Gna!
  http://gna.org/


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

Reply via email to