ExOK / Celeste64

A game made by the Celeste developers in a week(ish, closer to 2)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Localisation?

Oblait opened this issue · comments

Are they any plans to implement support for multiple languages/language selection?

My team would love to do an Arabic localization for this. The technical end of RTL shouldn't be a challenge as long as a Localization system is in place.

I'm not against localization support in the official build but it would require a few steps. I'm happy to look into some of these in the near future:

  • Dialog needs some a Dialog class, I imagine it would look something like:
public class DialogBank
{
    public string LanguageID;
    public string LanguageLabel;
    public string Font;
    public Dictionary<string, DialogLine> Lines;
}
  • Needs to load dialog from folders, like how other assets are loaded
  • When generating the Font for each language, it needs to know what charset to use (by querying the lines, probably?)
  • Ideally don't generate the font unless the language is actually used, since it's slow.
  • Some way to switch languages (either in-game or a just by editing the save... the in-game menu is getting kind of big though, so might need an actual options menu).

Thanks, Noel! Sounds great.

I'm not against localization support in the official build

Yeah, modding in language support would be relatively simple, but I'd rather localization of all things be more accessible tbh.

While we're on the subject - I know RTL is a pain, so we're happy to provide anything you need from bespoke fonts w/ licenses, feedback, or direct help with the code. This is mainly to avoid lagging behind once it's time to actually translate, as RTL languages often gets the short end of the stick in cases like these.

We've worked on games like Obra Dinn, Tunic, and most recently VVVVVV and provided implementation consultation & support next to the localizations - so we got RTL support down to a process at this point.

That should keep hair-pulling to a minimum I think. Feel free to ping/reach out anytime.

I think for RTL the biggest thing is making the sprite batcher text rendering be able to handle it (https://github.com/FosterFramework/Foster/blob/main/Framework/Graphics/Batcher.cs#L1607), and to also query the font for information on whether it is RTL (unless the character advance is just negative?)

Changing the xadvance for the characters to negative instead of positive, plus adjustable text alignment (I mean the left/center/right setting) could do the trick.

Even if you can't do that or don't think changing the code is possible to accomodate one language, please still give it a try (we just need access to the fonts and full text), then we can figure out a workaround just working with the Latin codebase and see what needs to be ironed out later.

I'm not against localization support in the official build but it would require a few steps. I'm happy to look into some of these in the near future:

  • Dialog needs some a Dialog class, I imagine it would look something like:
  • Needs to load dialog from folders, like how other assets are loaded
  • When generating the Font for each language, it needs to know what charset to use (by querying the lines, probably?)
  • Ideally don't generate the font unless the language is actually used, since it's slow.
  • Some way to switch languages (either in-game or a just by editing the save... the in-game menu is getting kind of big though, so might need an actual options menu).

If you didn't make the game with internationalization in mind, I suggest this possible approach:

  • Go through all of the text in the game and assign IDs to each dialogue. Just the ID is enough. So each line has an English string (the fallback, the way the game works right now) and an ID (can be numerical, per stage, etc).
  • A csv or tsv file with all of the game text. Columns would be the ID, the English text (for reference, doesn't do anything), possibly some columns for the speaker/gender/portrait and translator notes (doesn't do anything), formatting (left/center/right alignment, text speed, etc. Might be 0 if set to not override the English text settings), and last but not least all of the possible languages as separate columns.
  • You could add a language select (please avoid flags).
  • As for how the game would fetch its dialog... English would use the fallback string, like it does right now. Any other language would parse the ID, look for what matches that ID under that language code's column (or maybe it could fetch it from a numbered column? idk), and then if it's not blank it would use that string to override the English line otherwise it defaults to the original.
  • A configuration file shared by all languages, whether raw text, xml, json or whatever, would have a list of languages, what they're called (for the language select option), which font name they use (many fonts can be defined if there's multiple styles), and any global considerations for how they display (like Arabic using RTL, French/German being scaled 80% horizontally, etc) as well as a line for English defining the universal fallback settings (fonts, text bubbles, etc).
  • Text encoding shall be UTF-8 (16 bit Unicode codepoints) for all languages. If English uses ASCII it can be set aside as a special case but that's the least painless option.
  • That csv could be loaded at all times (or partially?) whenever there's a non-English language selected, different fonts for each set of languages (not a 23MB Arial multilanguage font, but rather an assortment of 500kb fonts for Extended Latin+Greek+Cyrillic, another 500kb one for Arabic, and three 4MB CJK fonts for JP, CH or KR. only loaded on demand and otherwise unloaded. For the language select strings you could pre-generate textures of every single language's string as graphical text to optimize away that loading part)

The basics for this are set up, and in theory should work for any LTR language. Further issues:

  • Need a way to select them from the options menu (probably with a Slider Enum as discussed i #43)
  • Need to be able to handle RTL which, again, probably needs to be done in Foster.

Cool, we'll get to it and we should have something cooked up by next week I reckon.
I have some other minor suggestions for the loc process but @DreamPlusInfinity covered almost everything, so I'll leave those to after we're done.

Related to this, I noticed 2 minor issues where the Language wasn't getting loaded correctly from the save file, and made a PR for them here:
#73

Related to this, I noticed 2 minor issues where the Language wasn't getting loaded correctly from the save file, and made a PR for them here: #73

Thanks, merged that in!