Modular naming system

[Uwuewsky]

Is your feature request related to a problem? Please describe.

The number of translated strings exceeded 90'000 - that's more than 1'000'000 words! Such a huge number leads to inconsistency and errors not only in translations, but also in the source strings.

There are a couple of places in particular that, by changing them, this volume could be significantly reduced without removing anything from the game.

1. Too many variations of items. Items, usually armor, have XL/XS variants, different steel/fabric variants, variants (on/off), light-medium-heavy variants. If this seems not enough for you, then there are also options without sleeves, reinforced, and others. The absolute peak is the brigandine. One set of armor consists of 180 items.

• This also includes descriptions of these items. For many similar items, the description differs by a repeating pair of lines.
• This also includes decorative, colored versions of items. A couple of dozen pants in barely discernible shades, a whole pack of smartphone cases with all kinds of prints, jewelry (431 pieces) made of all kinds of metals with all kinds of gems.
• This also includes book variants. We have >30 books on programming and all 50 volumes of the Talmud. This often leaves the player confused - 3 books with "get coding" in the title ("Let's Get Coding", "Get Coding!", "Get Coding 2!") and a bunch of other books with approximately the same title ("The Ultimate Guide to Knife Throwing", "The Complete Knife Throwing Guide").
• This also includes terrain/furniture variations. Open, closed, locked, boarded up, broken doors with/without peephole and others give a lot of stress.
• This also includes other variations of items, such as magazines for 5, 10...45 rounds. Casings and others.

2. Nested groups in the crafting menu. In almost all cases, it duplicates the names of a considerable number of objects in the plural.

3. Camp recipes. (data/json/recipes/basecamps) Like point 2, but hundreds times worse. Once again its duplicates recipes, an number of times repeats the names of extensions with numbers and cardinal directions, and something else. (The nineteenth continuation section of the salt water pipe.)

4. Martial arts log messages. There is a separate message for each strike. More precisely, two, there is a separate line for NPCs. Many monsters have unique attacks.

Solution you would like.

P 4. I don't think there's anything that can be done here, so let's skip it.

P 2 and 3.

• Use dynamic naming.
• Use existing names where possible. There are already a couple of cases where the name of the item and the group are the same:

  #. ~ Item name
  #. ~ name of the nested group
  #: data/json/items/armor/torso_armor.json data/json/recipes/nested.json
  msgid "medium steel mirror armor"
  msgid_plural "sets of medium steel mirror armor"

P 1.

• Items need roughly the same system that is already used to add state to the name:

  #. ~ This is a string to construct the item name as it is displayed. This
  #. format string has been added for maximum flexibility. The strings are:
  #. %1$s: Damage text (e.g. "bruised"). %2$s: burn adjectives (e.g. "burnt").
  #. %3$s: tool modifier text (e.g. "atomic"). %4$s: vehicle part text (e.g.
  #. "3.8-Liter"). %5$s: main item text (e.g. "apple"). %6$s: whitelist marker
  #. (e.g. "⁺"). %7$s: tags (e.g. "(wet) (poor fit)").%8$s: inner contents
  #. suffix (e.g. " > rock" or " > 5 items").
  #: src/item.cpp:6897
  #, c-format
  msgid "%1$s%2$s%3$s%4$s%5$s%6$s%7$s%8$s"
  msgstr "%1$s%3$s%5$s%4$s%6$s%2$s%7$s%8$s"

• Create names dynamically. Or it can even dynamically create variants of the items themselves from JSON, including material, size, and state.

• Create descriptions dynamically, which has already been done in some places for colored items, such as skirts, where the color description is concatenated to the rest of the description.

• Similarly for terrain.

• And preferably, in general, wherever there are repeating substrings.

• Control the growth of the number of decorative variants. (while I was writing this issue, someone added almost hundred more board games)

  name[0] - "XL"               - "XL"
  name[1] - "tempered steel"   - "из закалённой стали"
  name[2] - "light close helm" - "лёгкий закрытый шлем"
  name[3] - "(raised)"         - "(подн. забрало)"
  --
  <name_template_armor_helmet>
  "%1$s %2$s %3$s %4$s" - "%1$s %3$s %2$s %4$s"
  --
  "XL tempered steel light close helm (raised)"
  "XL лёгкий закрытый шлем из закалённой стали (подн. забрало)"

• The number of translated strings is minimal. If a new item is added, only one item needs to be translated, not a hundred variations of it. If a new metal is added, only the metal needs to be transferred, not the entire arsenal.

• You may have to specify different templates for different types of items.

• This system ("%1$s %2$s %3$s") is probably flexible enough for each language.

Describe alternatives you have considered.

The current naming system is incredibly inefficient. I'm not suggesting a specific implementation of a way to solve this problem, so alternatives are possible.

Additional context

Mock-up? Uhm... Something like this, purely for representative purpose:

{
  "id": "9x18mm_casing",
  "copy-from": "casing",
  "looks_like": "9mm_casing",
  "type": "GENERIC",
  "name": {
    "str": ["9x18mm", " casing"],        // <-- These strings exist separately in translations,
    "template": "<name_template_casing>" // <-- are concatenated when necessary, and reused in different places.
    },
  "description": {
    "template": "An empty casing from a %s round.", // <-- idk, something like this  would be useful
    "placeholder": ["9x18mm"]                       // <-- 
  },
  ...
}
{
  "id": "xl_lc_lighthelm_close_raised",
  "type": "ARMOR",
  "name": {
    "str": ["XL", "mild steel", "light close helm", "(raised)"],      // <--
    "str_pl": ["XL", "mild steel", "light close helms", "(raised)"],  // <--
    "template": "<name_template_armor_helmet>"                        // <--
  },
  ...
}
{
  "type": "terrain",
  "id": "t_door_boarded_damaged_peep",
  "name": {
    "str": ["boarded up", "damaged", "door", "with peephole"],  // <--
    "template": "<name_template_terrain_door>"                  // <--
  },
  ...
}
{
  "id": "qt_cutlass",
  "copy-from": "mc_cutlass",
  ...
  "description": [         // <-- the first part is repeated in every cutlass, the second in every tempered sword
    "A broad saber known for its use by sailors and pirates, as its short blade is easy to handle in close quarters.",
    "\n\nMade of tempered steel, this is a masterpiece.  The grip, the balance, the blade, all perfect.  This is the peak of the swordsmith's craft."
  ],
  ...
}

There is a second solution - to make a system for defining all variants of an item from one JSON. All variants are created automatically, eliminating the risk of creating a bug somewhere in one of the (5 materials 3 sizes 2 states) 30 items (90 if you include light/medium/heavy) in the worst case. Of course, changing such a core system will be intensive.

{
  "id": "light_helm_close",
  "type": "ARMOR",
  "category": "armor",
  "name": { "str": "light close helm" },
  // ...
  "possible_materials": [
    {"material": "lc_steel", "override":{"armor": [/*...*/]}},
    // ...
    {"material": "qt_steel", "override":{"armor": [/*...*/]}}
  ],  
  "possible_sizes": ["XL", "XS"],
  "use_action": {
    "type": "transform",
    "target": "raised",                   // <-- subvariant created automatically
    "msg": "You raise the helm's visor.", //    xl_qt_light_helm_close_raised
    "menu_text": "Raise",
    "suffix": "(raised)",
    "override": {
      "armor": [/*...*/]
    }
  }
}

I repeat, the problem is not having thousands of items, but having a million words to translate, and the absence of any system that could effectively reuse the strings.

[Zireael07]

Can the proposed system handle the fact that the order of $1 $2 $3 may be different across languages?

Otherwise, an excellent suggestion if I may say so, as a translator by trade.

[Procyonae]

67615 for my views on XL/XS and grades though from an angle of awful maintainability and prone to mistakes rather than a translation perspective

Generally agree with everything you've said, I'd be interested on hearing @sadenar's opinion on the implementation you've suggested

[Qrox]

Can the proposed system handle the fact that the order of $1 $2 $3 may be different across languages?

The order of the components can be rearranged, but some languages not only require a different order of words, but also require words to be in different forms when near different words (declension for example, and we also have this weird tendency to use phrases with even number of syllables when writing Chinese, so the number of characters of a component may affect how we translate a nearby term).

I suppose the benefit of doing so outweights the drawbacks in most cases though. Do note that we already have something similar in the game (the conditional name system), so we can probably parameterize the variant stats, merge variants into a single item, use the conditional name system, and extend it to item descriptions.

[CoroNaut]

I am very for this change as per #69541 which outlines that the crafting window is bloated and could potentially have some pruning of versions of items that aren't your size. With the variations as you suggest, I can see that being possible.

This may also be able to close #69204 if the idea here is also to fine-tune wearing such clothing. This can also close #50891, and potentially provide an encumbrance difference for all sizes of clothing without needing to specify it for individual items.

Not to mention that the debug spawning of clothing could be fixed to list fitting clothes rather than all "too small" or "poor fit" clothing.

[IdleSol]

I apologize for the quality of the text. Deepl translate is used.

The order of the components can be rearranged, but some languages not only require a different order of words, but also require words to be in different forms when near different words (declension for example, and we also have this weird tendency to use phrases with even number of syllables when writing Chinese, so the number of characters of a component may affect how we translate a nearby term).

Using simple sentences, should help. Or separating into different lines. "Big fur pants with red stripes". Turning:

Pants
Size: Big
Material: Fur
Color: -
Ornament: Red stripes

From a player's point of view. I don't see the point in having to specify size and material in the name of an item. In everyday life you don't say: I'm wearing big underpants made of cotton, with a heart drawn on them.

In any case, when I look for an item, I start with its "base name". I need a gambeson. Then comes the specification of what kind of gambeson: kevlar. If necessary: normal size. Color is not a concern at all.

When it comes to comfort, it's more a matter of habit. To look in the title or in the description of the item on a special column, to understand whether I need this item. Moreover, I still look at the description when looking for things made of a certain material, because not all of them are specified in the title.

Can we enforce the rules on item naming and description? And who will redesign the existing ones. And wouldn't it be easier to rework the entire item description system than to try to fix the existing one.

P.S. To the question about translation errors. There is an item: "XL item". When translating I met variants when it turned into item XL, item XS. Once upon a time, there were variants of big item and small item.

Using padded arming pants as an example: утеплённые стёганые штаны https://cdda-guide.nornagon.net/item/gambeson_pants?lang=ru стёганые штаны XL https://cdda-guide.nornagon.net/item/xl_gambeson_pants?lang=ru стёганые штаны XL (But they're XS) https://cdda-guide.nornagon.net/item/gambeson_pants_xs?lang=ru

Off topic, but is the translation even correct? And I have a question, probably a silly one. If the author corrects the name of the subject, will the translator recognize the change?

[Qrox]

Using simple sentences, should help. Or separating into different lines. "Big fur pants with red stripes". Turning:

Yeah, I think that would also work. Though when it comes to the material it should probably still be mentioned in the name because it will affect the item stats. We could go with pants (cotton) which should solve the declension problem.

When it comes to comfort, it's more a matter of habit. To look in the title or in the description of the item on a special column, to understand whether I need this item. Moreover, I still look at the description when looking for things made of a certain material, because not all of them are specified in the title.

Placing some of the properties of the item in the name should help people quickly understand the stats of the item, but I agree that fluff properties do not have to be in the name.

Can we enforce the rules on item naming and description? And who will redesign the existing ones. And wouldn't it be easier to rework the entire item description system than to try to fix the existing one.

If we switch to a new system we can gradually migrate existing items to the new format, but I don't think there will be an easy way to automatically enforce the rules.

Off topic, but is the translation even correct? And I have a question, probably a silly one. If the author corrects the name of the subject, will the translator recognize the change?

Errors tend to happen in this kind of copypasta situation so that's another reason to move to a more modular system. To answer your question: when the name is changed in the code, a new untranslated string will appear on Transifex, so translators should be able to notice the change.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.