Dynamically generated localization keys

[BraedonWooding]

Issue by koosemose
Thursday Nov 03, 2016 at 11:49 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
Originally opened as TeamPorcupine/ProjectPorcupine#1609

---

Currently localization keys are explicitly set in the xml, however in nearly all cases the localization key for the name is some form of the item's type, and the localization key for description is that plus _desc.

With the changes to item types in #1607 (rename all items to use the same scheme) this makes the localization keys item_class+item_type, and for description +_desc. We could easily have GetName() return the class shorthand + the item type, and have GetDescription return that plus _desc.

Pros:
No need to explicitly set Localization Codes in xml
Localization codes will follow a consistent scheme (so long as the item type is kept consistent)

Cons:
It may not be obvious to new developers/modders what the appropriate localization code for an item would be.

[BraedonWooding]

Comment by UnknownSoldier1
Thursday Nov 03, 2016 at 13:19 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

I think I would be against generated keys, because this one con might actually make this entire system a pain. I want to have this extra key in the xml and have it really obvious rather than having it generated and maybe having to debug something that really shouldn't have to be debugged.

[BraedonWooding]

Comment by dusho
Thursday Nov 03, 2016 at 16:19 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

I would be also against having some 'magic' link between things that is not obvious from looking at .xml files. Having things explicitly in .xml may be too verbose, but modders don't have to deal with all the magic rules that may be applied to various things

[BraedonWooding]

Comment by Geoffrotism
Thursday Nov 03, 2016 at 20:37 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

I'm all for this. Just add a _readme to the top of the localization folder that explains the process.

[kd7uiy]

Let's do this the half-way method. By default, we can use procedurally generated keys, but we can override them if required? I can imagine there will be a few situations where using the same name might be useful, this will just make it easier to do so.