Enchanced string lists editing

[Polda18]

Describe the problem

Currently, string lists are edited each node as a separate entity with its own translation key (such as general-settings->description->[0]). That means each string node in string list has to be edited separately. Which for translating multiline messages that are saved in this format (for example lores for GUI items in a Minecraft plugin) means every single line has to be edited separately.

Describe the solution you would like

Replace single string entity (such as general-settings->description->[0]) with a multi string entity, if the source language file contains that translation in the string array format (so key will only be general-settings->description, and all array items will be on the same page). Either have multiple inputs per array item (with a function to add or remove lines as applicable), or have one multiline input for the entire array, and treating each line as its own array item (which honestly would be much better and quicker for editing). Array translation nodes could be noted with an icon next to the translation key.

Describe alternatives you have considered

No response

Screenshots

Translation key and translation interface:

Surrounding translations:

Additional context

I translate mostly from English to Czech (and vice versa), which means that multiline translations often don't match exactly, and the resulting translation may be longer or shorter than the source language item. That leaves two options: either add or remove lines as needed, or shrink or expand the column width as needed. Currently only the latter is applicable in Weblate, as I can't add or remove lines, they're fixed to the amount used by source, which makes it quite annoying to work with when the resulting translation is shorter or longer than source. Also, for example the lore line in Minecraft is limited to certain amount of characters before it starts wrapping around, which means I can't expand the line width indefinitely, and certainly can't shrink it indefinitely (to the point where there is just 1 word per line). Having this proposed ability would greatly improve the translations quality.

[github-actions[bot]]

This issue has been put aside. It is currently unclear if it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate.

Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

[Polda18]

I'm not sure if I picked it up correctly, but I've already stated a use case example inside. I'm translating plugins on our Minecraft server, and many language files configure GUI in the game (inventory GUI, where each item is given a specific name, lore, and a function that gets executed upon clicking that item). Lore lines are specified as a string array in those language config files, and Weblate currently treats each array item as a separate entity for translation, which majority of time makes it painful to translate, because array items are supposed to be lines of text, and treating each line separately breaks the translations apart.

[comradekingu]

You want more editable strings grouped in the regular editor? If it is just the grouping, I think searching and marking as labels suffices. As a stopgap measure those labels can be opened in the Zen editor.

Not that it matters much, but generally I am not a fan of having more strings per effective key, because the "mark as needing work" is only binary and available to everyone.

There is less knowing what went wrong in plural strings for this reason.

Reuse the label system and replicate the hierarchy there with multi-relational labels?

All descriptions of one menu are the label, belong to that menu. All descriptions are the same label. All error messages are the same, and it could also be one of the strings in one scope of communication.

This would greatly improve the ability to fine-tune the information displayed for each purpose of a program. Doing it mentally and trying to show developers looking at single strings without having a whole lot more to show is not easy, or hard work by making manual service design pathways as mockups, and understanding better what part of the program or otherwise is being translated.

If I can say "Look, this is all the information available in sequence. This is not needed, and this is only relevant once it shows up in the attached error-message it produces." that helps show something clearly quickly. It may also pinpoint what is often only a hunch, or make reporting back on fixes more structural for everyone.

[Polda18]

I'm not sure what you mean. What I'm talking about is something like this:

night_vision:
  slot: 0
  material: GOLDEN_CARROT
  name: &6&lNight Vision
  lore:
  - '&7This item will grant you'
  - '&7exactly 15 minutes of'
  - '&6Night Vision &7effect.'
  - ''
  - '&cThis item is consumed'
  - '&cwhen used.'
  effect:
    id: NIGHT_VISION
    duration: 900

See how the lore expands over 6 lines? And how the lore is stored in the YAML configuratio file as an array? This is also how Minecraft itself stores the lore. Each line is an item in an array of strings. The NBT data of the item stores lore as array of string, where each array item represents a single line. Having those lore lines be represented as a standalone item is time consuming for any edits.

This "Zen editor" you're talking about, what is it and how does it work? I haven't seen anything about it in the documentation. This grouping you talk about, what exactly does it?