Build translation workflow

[benweatherman]

• Option 1: Use translation API, then have humans check
  • Might be more expensive because humans would charge hourly instead of per word
• Option 2: Have humans translate
  • Might be cheaper because human time is charged per word instead of hourly
  • Memory tools can optimize and make human translators cheaper

Some initial thoughts

Perhaps use wagtail-modeltranslation or wagtailtrans

• Show translatable fields along with the text to be translated

• Alerts when content changes & needs to be translated

  • Translators should be able to take action on alerts easily (reply to email, obfuscated link to make updates, etc)

• Preview translated page

• Expose translated content via API (perhaps using accept-language header?)

  Open questions

• How do we translate alt text for images?

[amenity]

@benweatherman can we sync up on the methodology we're using here? I assumed we would be utilizing the vendor tool and consuming content microservice-style rather than building the interface into our CMS.

[benweatherman]

I was basing this off some initial conversations, I definitely don't know enough about the workflow to say this is the way it'll work. Do you have more info on how we might interface with the vendor tools?

[amenity]

We don't have more information on what vendor tools will be used. My understanding is that some include the translator editing interface, so we should not invest in building anything extensive ourselves.

If CPIO is still in the evaluation process, we should ask to see the APIs for tools they are considering and make a recommendation regarding which might integrate most easily with Joplin.

[benweatherman]

To consolidate some IRL convos, we're going to:

1. Check the progress of choosing a translation workflow/software
2. Not spend much time building things into the CMS until we know what we'll need for user testing and alpha release