TXT tags

[sampedestal]

Are TXT tags neccesary? Can I just input the desired string instead?

Like, instead of:
<Description>TXT_KEY_RESOURCE_COPPER</Description>

Can I have:
<Description>Copper</Description>

?

 

[alpaca]

Technically, only if you want localization. However, if you think someone will ever create a translation for your mod, it's a very good idea to use them.

 

[Spatzimaus]

There are actually a couple places where the game does this already. For instance, the Longswordsman unit doesn't use a TXT_KEY; the game sets the name directly. That means that any French or German version, for instance, would still use the English name.

For modders it's a toss-up. The chances of anyone ever going to the effort of translating your mod into another language are slim, and there are some Lua things where it'd be awkward to try making it delocalized. But then again, there's little reason NOT to use TXT_KEY entries. And it saves room; sure, you could replace "TXT_KEY_FACTORY" with the word "FACTORY", but try placing the paragraph-long "TXT_KEY_FACTORY_STRATEGY", or even the one-sentence "TXT_KEY_FACTORY_HELP" (which just says "Requires 1 [ICON_RES_COAL] Coal.") into the existing blocks. If you put these into the Buildings table directly, it'd take up WAY too much room, so it's convenient to put them in a side file.

There's also the advantage of duplication. For instance, in my own mod, I gave city-states "Secondhand" versions of many industrial/modern units (the Tank, the Fighter, etc.); these units have stats nearly identical to their normal counterparts, just a bit weaker and they don't require strategic resources (since city-states won't have those resources). It's a very handy change to the game, but I don't want separate Civilopedia entries for these. I don't even want separate tooltip entries, because the player would never read those. So I only created one new text key (the base one that just lists the unit's name on mouseover), and the rest all point to the old unit's entries.

But if you're making a small mod and don't intend to ever translate it to other languages, then it really doesn't matter much one way or the other.

 

[alpaca]

Another advantage is that the text keys are all in one place and re-usable. So if you use a text key in multiple locations (which is very likely for something like a resource) you would have to go through each if you want to change the name, while you would only have to make one change if you use the key.

 

[Spatzimaus]

Another advantage is that the text keys are all in one place and re-usable.

Also, if you decide to rename something to fit your own tastes (like changing the Modern Era to be the "Nuclear Era"), it's easier to make sure you found all of the instances of this if you don't have to root around in a dozen directories. Keeping all of the text keys in a handful of gametextinfo files makes this much easier, even if you didn't have any overlap between the tables that use the text keys.

One of the things to note, though, is that the name of a text key doesn't have to have any relation to the thing inside it. The naming formats for the existing keys can be pretty arbitrary (whether a unit's text key has _CIV5_ in the name, for instance), and there are even a few mistakes (they misspelled "Penicillin" in its text key's name, with only one L, but got it right in the entry itself). So if you're going to edit existing keys, make sure you have the name right first.

 

[Ryan F. Mercer]

Incidentally, if you ever wish to use a text-key within text, use curly-braces, ie: "Imbedded {TXT_KEY_EXAMPLE} text."
_

 

[alpaca]

Incidentally, if you ever wish to use a text-key within text, use curly-braces, ie: "Imbedded {TXT_KEY_EXAMPLE} text."
_

Is that resolved automatically or do you have to call ConvertTextKey with a second argument?

 

[SamBC]

It apparently works with keys added to the DB, so it seems likely it would be handled automatically in LUA similarly.

 

[Spatzimaus]

Is that resolved automatically or do you have to call ConvertTextKey with a second argument?

As far as I can see, resolved automatically. Here's an example from the Civilopedia text file (very bottom of the file):

<Row Tag="TXT_KEY_CIVILOPEDIA_SPECIALABILITIES_YIELDCHANGES">
  <Text>{@1_ImprovementDescription} {@2_YieldDescription} {TXT_KEY_ABLTY_YIELD_IMPRVD_STRING} {3_Yield}</Text> 
  </Row>
<Row Tag="TXT_KEY_CIVILOPEDIA_SPECIALABILITIES_NOFRESHWATERYIELDCHANGES">
  <Text>{TXT_KEY_ABLTY_NO_FRESH_WATER_STRING} {@1_ImprovementDescription} {@2_YieldDescription} {TXT_KEY_ABLTY_YIELD_IMPRVD_STRING} {3_Yield}</Text> 
  </Row>
<Row Tag="TXT_KEY_CIVILOPEDIA_SPECIALABILITIES_FRESHWATERYIELDCHANGES">
  <Text>{TXT_KEY_ABLTY_FRESH_WATER_STRING} {@1_ImprovementDescription} {@2_YieldDescription} {TXT_KEY_ABLTY_YIELD_IMPRVD_STRING} {3_Yield}</Text> 
  </Row>

This line creates the entry in the Civilopedia for each tech (not to be confused with the tooltip on the tech tree), the one that creates the "Special Abilities" box for that tech. It's paired with a Lua command that passes three arguments based on the tech's actual bonuses:
@1 becomes, say, "Farm"
@2 becomes "Food"
@3 becomes "1"
TXT_KEY_ABLTY_YIELD_IMPRVD_STRING says "yield improved by" in english
and TXT_KEY_ABILITY_FRESH_WATER_STRING and NO_FRESH_WATER_STRING just say "Fresh water" or "No Fresh water", respectively.
(The Lua that sets the tooltips on the tech buttons is TechButtonInclude.lua, but I don't know which one sets the civilopedia pages.)

So, if you right-click on Civil Service to see its civilopedia page, it'll say "Fresh water Farm Food yield improved by 1" in the "Special Abilities" box.