Issue: Localizing YAML templates
Issue:Â - LOC-76Getting issue details... STATUS
Template YAML files
The current approach taken is to create a locale-specific clone of each YAML file. The Arabic versions live under an 'ar' directory, and each clone contains an Arabic translation of the data
 section. For some reason, the English language text int the metadata
 section was left untranslated.
It seems clear that this is not the correct approach. Translators would find it very difficult to update text directly in a YAML file, as they have an esoteric structure and it is not clear which pieces of text require translation. It also seems a mistake to have copies of each file as non-language changes will need to be replicated into every translation.
Ned Batchelder has the following recommendation:
- support the sameÂ
_("...")
 Python-style syntax in YAML as used in HTML files - translated strings would then live in the same files as for most other parts of the product
- a Babel plugin for YAML would be provided to extract the i18n strings
- YAML rendering in the front-end would regex replace theÂ
_("...")
 with the locale-specific string - Update: it would probably be better to convert the files to use Mako to be more consistent with how other file types are handled. How feasible is this?
For example, here's what checkboxes_response.yaml
 might look like:
Â
--- metadata:     display_name: Checkboxes     markdown: |       _("A checkboxes problem presents checkbox buttons for student input. Students can select more than one option presented.")       [x] _("correct")       [ ] _("incorrect")       [x] _("correct") data: |       < problem >         < p >_("A checkboxes problem presents checkbox buttons for student input. Students can select more than one option presented.")</ p >         < choiceresponse >           < checkboxgroup  direction = "vertical" >             < choice  correct = "true" >_("correct")</ choice >             < choice  correct = "false" >_("incorrect")</ choice >             < choice  correct = "true" >_("correct")</ choice >           </ checkboxgroup >         </ choiceresponse >       </ problem > |
Â
Another option would be to move this content out of the source code entirely and treat it more as content in a repo. This would essentially be prototype content that could be managed entirely separately. In some ways this makes more sense, as the desired set of templates is very specific to each organization.