What are better methods for TextMeshPro localization?"

Unity Engine
, , , ,
1

Hello,I am an asset publisher based in Japan, specializing in selling assets for visual novels.
I am reaching out to inquire about better localization methods for TextMeshPro.

Approach 1: Swapping TMP_FontAsset
This approach involves the complexity of needing a dedicated component for each Text object. It becomes more complicated when using extended MaterialPresets like Outlines. It seems that MaterialPresets with the same naming conventions for different languages would be required, making it not the most ideal approach. However, there seems to be something similar to this approach in Unity’s PackageManager called the “Localization Package” (though it’s somewhat complex).

Approach 2: Leveraging the Fallback Mechanism
This approach suggests keeping the base TMP_FontAsset as is and adding fallbacks at runtime. For example, using NotoSans as the base font and adding NotoSansJP as a fallback for Japanese and NotoSansKR as a fallback for Korean at runtime. In practice, for development primarily in Japanese, you would use the base NotoSans with the added NotoSansJP fallback in the editor, and then switch the fallbacks at runtime based on the language. However, there are concerns with this approach:

Concerns:

  • Changing the content of assets (fallback tables) at runtime, potentially affecting values even during editor play mode. Is there a solution other than writing a program to manually revert the changes?
  • Is it possible to set up persistent (runtime-only) fallbacks similar to UnityEvent.AddListener? This should also disable any fallbacks set in the editor and only enable runtime fallbacks.

I’m not considering dynamic fonts or dynamic OS fonts here. I think of it as a last resort.
Additionally, in either case, the following steps are expected:

  • Maintain a consistent ratio of Padding/PointSize across all FontAssets, including fallbacks.
  • Attempt to unify TextMetrics (FaceInfo) as much as possible.
  • In Asian fonts, there are many characters, so we need to split the font assets into multiple parts to accommodate them.

I am leaning towards adopting “Approach 2.”
Are there any anticipated issues with my approach, or do you have any suggestions for a better method?

I appreciate your assistance and guidance on this matter.

2

“Approach 2” will create a lot of submeshes.
It would be better to create a runtime material pool, using the format {font-originMaterialName} - {material} and then call SetSharedMaterial().

3

Thank you for your response.
So, are you suggesting creating a dynamic Material table for runtime? That sounds like a good approach.

However, it seems unavoidable that we’ll end up with more sub-meshes, so I believe we’ll have to accept this limitation. Asian characters are incredibly numerous, and a single font asset can cover only a limited set of characters. In my project, I aim to cover as many characters as possible.

Regarding the increase in subMeshes, the author of TextMeshPro seems to say that it is not a big problem.

However, there are many other topics on the forums about DrawCall and batching in TextMeshPro.
I don’t know much about them.
Is it an old problem that has been solved, or is it still something that should be strongly avoided?