Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translations #6

Open
drdnar opened this issue Jun 23, 2019 · 0 comments
Open

Translations #6

drdnar opened this issue Jun 23, 2019 · 0 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@drdnar
Copy link
Owner

drdnar commented Jun 23, 2019

The dungeon file architecture makes adding language translations fairly straightforward: just translate the dungeon file, and rebuilt that file.

Some additional code changes will be required to support fully other languages:

  • The string input routine only supports basic ASCII---and not even all printable ASCII can be typed. More sophisticated IME code will be required if you want vocabulary containing non-ASCII characters.
  • There are still strings scattered throughout the code that are embedded in the code, instead of being fetched from the dungeon file. These strings should also be fetched from the dungeon file.
  • To support fetching strings from the dungeon file outside of the game loop, the dungeon file should be loaded at startup. (There's no obvious way to handle translating the "dungeon file missing" message. . . .)
  • The Huffman decoding tree format I'm currently using is reasonably fast and compact, but is limited to 7-bit output codes. Supporting other languages needing characters not found in basic ASCII will either require a new Huffman tree format to support 8-bit output codes; or, if all languages we want to support can be squeezed into 120ish code points, a character translation table to map a custom per-language 7-bit code page into a standard 8-bit code page.
  • Need to make sure make_dungeon[_calc].py will translate Unicode in the input adventure.yaml to the correct output code page.
  • FontLibC fully supports up to 255 printable glyphs, so supporting non-Latin-alphabet languages won't require much additional code---will just want to ensure that the font used to display it has the correct code page. (Note that FontLibC does not support logographic/ideographic scripts, unless fewer than 255 glyphs are required.)

I have no plans to produce any translations myself, but contact me if you would like to provide a translation.

@drdnar drdnar added enhancement New feature or request help wanted Extra attention is needed labels Jun 23, 2019
drdnar added a commit that referenced this issue Jun 28, 2019
This actually doesn't really save any space, but at least it moves closer to translations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant