Limited language internationalization

[idler8]

Feature # .

Description of the problem being solved:

internationalization

Steps taken to verify a working solution:

-Options & Restart

Link to a build that showcases this PR:

No

Before screenshot:

After screenshot:

[idler8]

I found that many pull requests were not processed Is this project currently being maintained by anyone? I don't have any Windows devices on hand, I need someone to assist me with the first round of testing If it is possible to merge, I will continue to try more powerful internationalization features

[FWidm]

HI! PoeCharm already has some translations available if you just need it for personal use right now: https://github.com/Chuanhsing/PoeCharm

Is there a possibility to also split the translations into pure data and logic to apply them in your PR? (similar to https://github.com/Chuanhsing/PoeCharm/tree/main/PoeCharm/Pob/translate_cn )? Might even be worth it to check if some of the efforts could be split by using the same translations?

[idler8]

I don't recommend discussing fork warehouses that cannot be merged here

[zao]

Sorry for the delay in responding to this PR, I've been quite busy.

There's some technical and project-oriented constraints around localization.

On the technical side, the official Windows runtime doesn't handle or draw Unicode text yet as Lua(JIT) on Windows is fundamentally using the user's narrow ACP for strings and paths, which almost universally can't be UTF-8. I have limited support in upcoming work to represent paths and strings in Unicode and begin to handle Unicode cursor/deletion logic in inputs like file selection with placeholder display of any non-ASCII codepoints in tofu like [U+1234]. Similarly I've got past work on text rendering that could be rebased later for readable text rendering with text shaping and font use. Until that work lands, a translation effort like this would be completely unusable. Even with that - input is an unsolved problem as integrating something like an IME takes significant re-engineering of the UI.

I don't have many comments on the localization logic itself, except that substitution-based localization tends to be brittle and may not capture the proper context of the source text.

On the project side, a big hurdle about localizations is that they have to be maintained to react to changes in the source text and that they can't really be tested and adapted as part of a feature contribution unless the contributor understands all the languages. As such they tend to reduce development velocity, something that is highly valued around league start where we need to prototype features rapidly.

I deal mostly with the technical side, I'll leave the wider project operation concerns to someone else.

All in all, it's an interesting effort but as the Windows runtime currently exists it can't do anything meaningful at all.

[idler8]

From the user's perspective, as long as the functionality is not compromised, limited internationalization is much better than no internationalization If the difficulty of solving coding problems is greater than replacing it as a whole with another language, JavaScript is actually a better choice

[idler8]

I have done more international content locally, but it doesn't seem necessary to submit it at the moment. Using JavaScript, it is possible to package using Electron or launch it as a web application. These are all my scattered thoughts. If they conflict with the purpose of this project, please feel free to close this issue.

[Nightblade]

I don't recommend discussing fork warehouses that cannot be merged here

Why?