Common Mistakes in Translation Templates

[niccokunzmann]

When I am looking at translations of templates, I see some misunderstandings. Here, I would like to show some, propose a solution and open a discussion.

Examples:

• Splitting up the template boundaries: Adresse: < % = event.address %> https://crowdin.com/translate/zen-community-platform/1163/en-de#6336
• Translating parts of the template: <%= event.address %> => <%= event.addresse %>

Constraints:

• Boundaries must not be split up: Example: use these brackets: {}
• Something like "event.name" is preferred over "1" since the order of several templates depends on e.g. place, time, subject, object.
• Using numbers makes it clear that no translation should take place e.g. {1} instead of {name}

Proposal: Use templates like this:

• {1 name} or {1}
  • The number is the really important part: it identifies the value to take.
  • The other string value is used to provide context.
  • curly brackets remove the splitting problem

Questions:

• Is this really an issue?
• Can crowdin be instructed to make some kinds of strings immutable? For Links, this seems to be the case.
• What do you think?

[Wardormeur]

Wow, thanks for bootstraping the discussion :+1: So : boundaries recognition is set by Crowdin. There are scenarios where it works (https://crowdin.com/translate/zen-community-platform/43/en-de) , and other when it doesn't. Changing the boundary format may help (not composed) but it also an issue as ejs allows us to change the formatting result (ie : pure HTML or escaped) (difference between <%= and <%~ and so on). {1} would be an invalid object name in javascript, and {1 name} would require us to write our own templating engine.

Overall : yes : it's an issue. There are alternatives like extracting the strings out of the ejs, but it poses the issue of LTR languages or simply "sentence composition" afterwards (basically the same issue than messages.po when no "variable" is used). I think my first step would be to contact Crowdin to see if there is anything we missed that could ensure those boundaries are respected. If this doesn't work, some work need to be done to find "why" they're not recognised, or ultimately a boundary that is properly recognised. If it is properly recognised then the format of the variable shouldn't matter because crowdin will simply exclude it.

[Wardormeur]

Just to extend : we've added tests to cp-translations (mostly @DanielBrierton 's work !) for emails. This way, the deployment fails if the translation is faulty. That's not perfect (front-end translations are still an issue) but at least every email should now send.