Localization

[NQNStudios]

Addresses issue #14

Changes proposed by this pull request:

• Project configuration defines separate glob arrays for each language's markdown
• All languages are rendered into index.html with section id's postfixed by the language
• Templates define the location and visibility of a language dropdown menu
• GotoSection() will always go to the version of the section in the current language
• When the dropdown selection changes, the story is restarted in the new language

@invicticide to review

[invicticide]

This is a good start!

For identifying languages, we should adopt the ISO language/region standards, e.g. "en-US" for US English. They're widely standardized for localization and clearly disambiguate dialectic differences (e.g. "en-US" vs. "en-GB" for US vs. British English, respectively). Apple has a good reference doc with examples and links to the actual ISO standards docs.

I'm not sure we should pack all languages into the same output file. It means the more languages a game is localized into, the more data the end user has to download which they'll never actually use (i.e. all the languages except theirs). It may be better to output separate builds for each language, and have the language selection be something that's handled on the author's website, or through a store backend, or however they've chosen to distribute their story. I'd imagine outputting to locale subfolders, so you'd get e.g. build/en-US/index.html and build/pt-BR/index.html and so on. I'd also output the JS and assets to each locale folder so we don't have to do any path fixup between languages, and so each locale folder functions as a completely standalone build.

Which raises the question: how does localization for JS even work? It's likely text will be embedded in JS in some cases, since the whole point of function and variable macros is to return dynamic text. It's not clear how much of the responsibility for that lies with Fractive and how much lies with the author. I lean towards most of it being with the author just because those use cases are going to be varied and unpredictable, but this is worth considering.

There's a related question for localizing assets. I expect this will be rare in Fractive since it's primarily text-based, but if images/audio/video are included which need to be localized, there'd need to be a path for that as well. I'd think they can be handled the same as Markdown though, where they just live in locale-specific source folders.

[invicticide]

Thinking about this some more today, splitting the languages out into separate files like I previously suggested may actually be premature. I doubt we'll see a lot of games getting localized into a lot of languages any time soon; the most common use case will no doubt be single-language. And in that use case, I'd like to preserve the ability for the entire game to be deployed as a single HTML file, not a loader and then a language file.

Long-term, I could see adding a splitLanguages setting to fractive.json. It's false by default, which means we pack all languages into a single HTML file, more or less like your original implementation, and the title/loader div contains the language select. If it's switched to true, we generate a loader file with a language selector and then individual story files for each language. Either way, localized asset files are always put in language-specific subdirectories. This implies HTML files are always at the root and assets are always in language subdirectories, so relative asset paths work correctly regardless of the splitLanguages setting.

The one other wrinkle I'd add to this is that if a story is built with just one language, we should skip the language select entirely. It's pointless to show it if there's no choice the user can actually make.

[NQNStudios]

All of the above being the case, I might actually add that it makes more sense to let the user handle ISO standards if they want to. Players won't know what the ISO codes mean so we'd have to have both ISO code and human readable language name defined for each language anyway. The ISO standards aren't necessarily useful that I can think of unless we use the split directory structure.