Search the Community
Showing results for tags 'xml'.
Found 2 results
I know this may be controversial, but I think the current SpecificName scheme adds a minor amount of confusion, or at least a better scheme may add some more clarity where currently there is little. So, for example: <GenericName>Gallic Champion</GenericName> <SpecificName>Soliduros</SpecificName> This is actually a Swordsman, along with whatever that means to the game, but you don't know that from the name of the unit. What I would suggest is something like this: <GenericName>Champion Swordsman</GenericName> <SpecificName>Gallic Champion</SpecificName> <EthnicName>Soliduros</EthnicName> In the UI, it would show: Gallic Champion (Champion Swordsman) Likewise: Spartiate Hoplite (Champion Spearman) This now gives you a much better idea what "kind" of unit it is. The <EthnicName> "Spartiátēs" and "Soldurios" would show up elsewhere, likely in the Information viewer. Extended, we could give the player the option of what they want to see in the UI and tooltips.
Currently, unit template files have a translatable field called Tooltip. This field, as far as I’ve seen, may contain the following information: • Unit classes (recently prefixed by ‘Classes:’). • Units that this unit counters (prefixed by ‘Counters:’). • Units that counter this unit (prefixed by ‘Countered by:’). • Unit description. In the XML, these are differenciated by line breaks. What would you think about providing separated fields for each one of these? • DisplayClasses (as opposed to the class names used in the game logic) • Counters • CounteredBy • Description Pros would be: • Easier to keep consistency between tooltips. • Ability to use a different font or text style on different elements. • Ability to reorder the elements in the interface easily, without changing all XML files, nor affecting translations. • Ability to show a different combination of these bits of information in different contexts. • Easier for translator, as they would only need to translate the "Prefix: <data>" strings once, and the rest of the strings will have a decreased size. And I honestly cannot think of cons here. Also, if you agree, should I let you do this yourselves in master, or should I do this myself in my i18n branch? Or should I maybe write a patch against master only for this?