Issue: Localizing YAML templates

Issue:  LOC-76 - Getting 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.