adventure icon indicating copy to clipboard operation
adventure copied to clipboard

Add i18n support

Open finnp opened this issue 10 years ago • 4 comments

This PR adds the possibility to overwrite the English default Strings as requested in #6. The developer can pass an i18n object as an option mapping langage keys to alternative represenations (see /lib/en.json for english defaults). I didn't offer i18n support for strings that definetely seemed to be for developers only.

Also there is a new usage key which can be passed a readable stream providing an alternative usage template.

I used the visualwidth module to assure that it works for chinese character, too. However for chinese to fully work in adventure, terminal-menu has to be fixed (possibly with this https://github.com/substack/terminal-menu/pull/16)

finnp avatar Dec 16 '14 10:12 finnp

Regarding the i18n support. For the workshopper I used (my) i18n-core module that offers basic but relevant features like symbol replacements, fallback mechanisms, composite options and plurals. Perhaps its worth considering it.

martinheidegger avatar Dec 16 '14 17:12 martinheidegger

I intend to work on a branch this week that should use the same i18n behavior as workshopper, and submit that. This would help translators not juggle two distinct behavior sets across workshoppers.

Does that sound like something you'd be interested in?

Also, re: terminal-menu: it also completely breaks on lowercase diacritics (e.g. 'é'), which are super-common in, say, French, Spanish and Italian, to name only these. This does need fixing, haven't gotten around to it yet. Doesn't help that most workshoppers use an old terminal-menu though (new one still has issues on this, btw).

tdd avatar Feb 16 '15 07:02 tdd

Probably this problem? https://github.com/tokuhirom/visualwidth-js/issues/4

martinheidegger avatar Feb 16 '15 08:02 martinheidegger

Sounds likely, indeed. Reminds me that terminal-menu invokes visualwidth.width with a second arg at true, apparently for terminal mode (your code, right?) but the used module (0.0.1) does not feature a second parameter, as it was apparently not published to npm yet…

Not even sure that change fixes the issue, too.

tdd avatar Feb 16 '15 08:02 tdd