Ember-intl: Are there resources for helping maintain translations / automate PRs for updating language files?

[NullVoxPopuli]

• [x] I am on the latest ember-intl version
• [x] I have searched the issues of this repo and believe that this is not a duplicate

---

I'm currently using crowdin on https://github.com/NullVoxPopuli/emberclear/, but I've started ignoring PRs from CrowdIN, because they don't know how to handle commits to non english translation files. Their workflow is: make changes to the english files, then CrowdIN opens PRs to the other files... this works fine if you only interface with the crowdin UI -- but that's not ideal -- especially for open source projects..

[jasonmit]

All the companies I've worked for used proprietary solutions, so unfortunately can't help much here. I'll leave this open hoping a community member can come along and share a solution that'll work for you.

In the past, I've pulled translations at build time from external translation service APIs using the treeForTranslations hook:
https://ember-intl.github.io/ember-intl/docs/advanced/addon-support#advanced-usage-treefortranslations-

Most times though I had translators updating the translation files through internal processes which sounds similar to what Crowdin does (I've never used their service so I'm not certain).

[wopian]

You should never be directly committing changes to the non-default translations with CrowdIn (default being en-us in most cases, but whatever you configured when setting up the project or GitHub integration).

For example, https://github.com/NullVoxPopuli/emberclear/pull/992 should not have been merged and instead asked the contributor to make the translation changes on https://crowdin.com/project/emberclear/ru

---

CrowdIn does not do 2-way syncing for all language sources as it is prone to merge conflicts (syncs with GitHub at a specified interval, not on change), subverts all quality control and (ICU MessageFormat) syntax validation provided by the service and is open to ambiguous user error, e.g:

• If en_us added a new key:
  
  
  
  • acceptable: 'This is acceptable'
  
  
• A contributor added the new key to es_es on GitHub as:
  
  
  
  • aceptable: 'Esto es aceptable'
  
  

Is that a new string in es_es that needs to be synced to en_us and the other translations on CrowdIn or a spelling mistake? (Acceptable has 2 c's in English, but only one in Spanish)

[NullVoxPopuli]

That's why I opened this issue ;)

I've been fully aware of how crowdin wants me to work with the translation files, but I don't believe what crowdin does is the best way -- it's catered to non-OSS folks, :-\

We need something _better_, and it'd be fantastic to have a resource or service that provided a good way to manage translations, both from an app that requires login _and_ from source.

But maybe there is a different way entirely? something that allows for both workflows? idk