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

Comments

Projects
None yet
2 participants
@nwinter
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

This comment has been minimized.

Show comment
Hide comment
@nwinter

nwinter Jan 9, 2014

Contributor

See also #65.

Contributor

nwinter commented Jan 9, 2014

See also #65.

@nwinter

This comment has been minimized.

Show comment
Hide comment
@nwinter

nwinter Jan 14, 2014

Contributor

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

Contributor

nwinter commented Jan 14, 2014

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

@Sinza- Sinza- referenced this issue Jan 19, 2014

Closed

Translations #2399

7 of 10 tasks complete
@sderickson

This comment has been minimized.

Show comment
Hide comment
@sderickson

sderickson Aug 29, 2014

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.

Contributor

sderickson commented Aug 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@nwinter

nwinter Dec 14, 2014

Contributor

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.

Contributor

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 Dec 14, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment