Currently we use the engine translation features which allow us to translate lessons and practices partially: Every string is individually translated by calling the tr() function (This is also used to detect and extract strings to translate).
It works very well when you make a game because usually you only translate late in the production process when the content is relatively final. You ship a translation only when it's 100% complete.
For an app like this, we need to ideally be able to tweak the content freely. But a single letter or punctuation change invalidates a translation and, if we ship a release for the English version, it may prevent shipping e.g. the Chinese translations in the following release. This is in part because this is a free and open source project and translations are community made.
Suggested change of system
We could still use the tr() function from the engine to extract and maintain the translation strings.
However, this proposal is to build copies of the course in the target language at build time for a given version when translations are complete. Concretely, we would build probably lesson resource files like $lessonName.fr.bbcode, $lessonName.es.bbcode, etc.
Then, when we're about to build the next release, If the translations for a language are now incomplete, we can decide to keep the previous build files for lessons that are lacking up to date translations. We can also decide to ship the file and invite the community to contribute to translations.
This would allow us to address all the content papercuts that people report or change the content without risking invalidating languages that have a full translation of the course.
Currently we use the engine translation features which allow us to translate lessons and practices partially: Every string is individually translated by calling the
tr()function (This is also used to detect and extract strings to translate).It works very well when you make a game because usually you only translate late in the production process when the content is relatively final. You ship a translation only when it's 100% complete.
For an app like this, we need to ideally be able to tweak the content freely. But a single letter or punctuation change invalidates a translation and, if we ship a release for the English version, it may prevent shipping e.g. the Chinese translations in the following release. This is in part because this is a free and open source project and translations are community made.
Suggested change of system
We could still use the
tr()function from the engine to extract and maintain the translation strings.However, this proposal is to build copies of the course in the target language at build time for a given version when translations are complete. Concretely, we would build probably lesson resource files like $lessonName.fr.bbcode, $lessonName.es.bbcode, etc.
Then, when we're about to build the next release, If the translations for a language are now incomplete, we can decide to keep the previous build files for lessons that are lacking up to date translations. We can also decide to ship the file and invite the community to contribute to translations.
This would allow us to address all the content papercuts that people report or change the content without risking invalidating languages that have a full translation of the course.