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

Move i18n strings to the database #22

Closed
nwinter opened this issue Jan 1, 2014 · 4 comments
Closed

Move i18n strings to the database #22

nwinter opened this issue Jan 1, 2014 · 4 comments

Comments

@nwinter
Copy link
Contributor

nwinter commented Jan 1, 2014

Shortly after we launched our beta, we had so many amazing Diplomats volunteer from across the world to translate CodeCombat into ~20 languages before we could blink. We set up i18next to help translate our static text and also added an InternationalizationNode to Treema to help translate strings inside our levels. Cool.

But where did we put the i18next-based strings? Why, we just hardcoded them into a bunch of CoffeeScript files in app/locale and compiled them into the app, of course!

It's past time for that to change, since I can't keep manually transferring updates for all the languages from the exploding Google Spreadsheet we used to collect the initial translations into those locale files. Instead, we need:

  1. A way to store each locale in its own MongoDB document, so that a player can load only those translations she needs for her given language.
  2. An interface for Diplomats to use to edit and add translations. Perhaps we can use i18next-webtranslate instead of rolling our own? Otherwise, something involving Treema would probably make sense.
@nwinter
Copy link
Contributor Author

nwinter commented Jan 9, 2014

See also #65.

@nwinter
Copy link
Contributor Author

nwinter commented Jan 14, 2014

We may end up keeping these in the locale files for easy collaboration with GitHub. Not yet totally decided.

@sderickson
Copy link
Contributor

I think the best way to go forward with this is to have each locale compiled into a separate JS file and then loaded dynamically, like we do now for the test and demo views. For example.

@nwinter
Copy link
Contributor Author

nwinter commented Dec 14, 2014

Current system is working pretty well: website i18n strings are in GitHub, in separate .coffee files loaded as needed, and database content has its /i18n interface.

@nwinter nwinter closed this as completed Dec 14, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants