Add a newline variable that is only works in specific menus
nekochanfood
TextMeshPro has a system for making a new line to prevent overflows. but in Japanese, it makes a new line into an inappropriate place because there is no space for each segment. that's like a new line in the middle of "Apple".
So, I'd been inserting a new line ({ln}) in the string having a new line problem. but some of them have been used in multiple places such as MM, QM, and AM (Action Menu), I have come across cases where new lines are not necessary in MM, but are needed in QM.
So, I would like to be able to add a variable that adds new line when used in specific menus such as MM, QM, AM, etc.
For example, if
{mln}
is present in a string, it will break lines when used in MM, but not elsewhere.My suggestions are as follows:
- {mln}- Variables that are line-wrapped when strings are used in MM
- {qln}- Variables that are line-wrapped when strings are used in QM
- {aln}- Variables that are line-wrapped when strings are used in AM
The attached image shows how the string should preferably be displayed in both UIs.
Log In
Sayamame
I'm digging into the users' reactions to the Japanese localization.
There have been some comments about the position of line breaks, but without this requested feature, we are unable to fix the problem.
naqtn
Note. A discussion on the localization server about alternative ways of adopting standardized characters like U+200B ZERO WIDTH SPACE https://discord.com/channels/1096246414603997194/1097673670819840100/1236197869657129020
kawashirov
And btw we have similar problems in Russian too, as TextMeshPro breaks prepositions incorrectly sometimes.
Better be able to make explicit line breaks, than hope for TextMeshPro implicit mechanics.
kawashirov
It feels like complicated half-solution.
Better split the strings, so you can edit formatting how you like in every situation.
I believe it's better to keep things simple, any new mechanic is not necessary, when you can use existing one.
Sayamame
kawashirov But isn't it too much splitting to split strings with no essential difference in context...?
kawashirov
I am adepti of "own key for each instance of the string" approach (like in Minecraft).
I believe styling and formatting is a part of context too, not only grammar and meanings of things.
This is most flexible approach providing as many freedoms for translation, edits and formatting as possible.
It might not be necessary for you and your language now, but might be for others and different languages in future.
waso Keli
this would help toki pona too. i've been inserting line returns for readability and aesthetics, and removing them when strings are reused in various places.