Currently, we only support English as the main application language.
But there is no reason why there shouldn't be other languages available.
For example:
- English, Spanish, Portuguese, French, Russian; Chinese, Japanese, Korean, ...
Considerations and Roadblocks
- One roadblock is actually getting proper translations in the first place ^^'
- Make sure we get technical terms right
- As well as keep the spirit of how general UI is written in the origin language ('terse but hopefully intuitive/understandable English')
- References/easter eggs (rare)
- Requires us to factor out all user-facing strings so they can be swapped/selected at runtime (based on
Settings { language_selected: usize, .. })
- Way to store translations:
- Do we store a
struct UIStrings { pause_menu_name: &str, .. } per language (i.e. ".. -> [language -> [UI string]]")
- Or rather for each UI string an array of all the available language translations (i.e. ".. -> [UI string -> [language]]")
- Figure out how to factor out strings in a few weirdly coupled systems;
- E.g.
GameModifiers currently keep an array of custom information they would like to display in something like a ::values() -> &[(String, String)] call. But this currently couples labels to default to English. Instead, Modifiers might have to provide their own translation tables that can then be consumed by the frontend. Compare work to e.g. Noita (game with prolific modding community).
- (Along the way) Deal with further issues (big or small) that come up or weren't foreseen
- Always handling text length correctly: Forced to use
str::chars().count() (iterator len counting, instead of str::len() wherever it isn't done already?
- [Mostly for important CJK support] Handling scripts where graphemes take up more than one terminal cell of space?? This point is actually so big and problematic enough that it might warrant consideration of a rewrite into Ratatui for the menus frontend.
- Ask me about supporting scripts with a different writing direction (Arabic, Hebrew) once the terminals we run on have it figured out...
- Actual i18n work that goes beyond just replacing a single string with another (hopefully not much?)
Currently, we only support English as the main application language.
But there is no reason why there shouldn't be other languages available.
For example:
Considerations and Roadblocks
Settings { language_selected: usize, .. })struct UIStrings { pause_menu_name: &str, .. }per language (i.e. ".. -> [language -> [UI string]]")GameModifiers currently keep an array of custom information they would like to display in something like a::values() -> &[(String, String)]call. But this currently couples labels to default to English. Instead, Modifiers might have to provide their own translation tables that can then be consumed by the frontend. Compare work to e.g. Noita (game with prolific modding community).str::chars().count()(iterator len counting, instead ofstr::len()wherever it isn't done already?