Best way to bulk submit translations

We are currently working with a client that has a lot of custom translations in their fork. Some of these are for strings that are not in the regular upstream version, but there are also a lot of translated strings that are untranslated in the upstream version of edx-platform.

What would be the best way to submit the translations that are missing in edx-platform in bulk?

Also, what is the best way to handle translations for custom strings that aren’t in the upstream version of the code? For instance custom strings in the theme.

1 Like

Could you use tx push?

@xitij2000 I’ve had a similar case when I used to work for – the largest Arabic Open edX installation.

We ended up maintaining a separate Transifex project it was a lot easier to manage and it works with the existing Open edX tooling out of the box:

It might sound an overkill, but usually the cost of such Transifex forking is compensated by not having to edit anything on the code at all.

I did, and got some error probably related to permissions. I think I would need to be added to the correct team I guess. I will look into this again, and update.

Upstreaming is a core requirement, so that would not work for us. Currently the approach I am considering is moving all the translations to a custom plugin app that is installed just for the custom translations. For regular translations this should just work, but for the JavaScript translations, I’m trying to figure things out.

I don’t think that $ tx push work for both the edX team and the community. Transifex is not that smart and basically every $ tx push is more like doing a $ git push --force to the entire translation sources.

Upstream is definitely better than forking.

If all the changes are upstream and merged into the edx/edx-platform:master then the strings will end up on the edX Transifex without requiring you to have permissions to Transifex.

I suppose you’d like a mix of both:

  • Using the master edX platform.
  • Adding your code through some sort of plugin system.

Without having the complete picture I cannot provide a detailed solution, but here’s the alternative to a full fork – it’s partial forking:

  • Create a Transifex resource that you own e.g.
  • Push only the strings that you own to that resource.
  • When you pull, mix all the po files to create your own mo file that contains both of the fork and the upstream translations.

It’s easier said than done, and I used to do it before I opted for a full fork. Checkout this paverlib/ file that shows one way to do it.

@omar Thanks! I will investigate this approach.

If it’s not doable via a plugin or without requiring custom code this might be worth investigating as place where the platform can be enhanced to support this use case, since maybe it isn’t that isolated.

Yes, apparently it’s not isolated use case. I think every large non-English Open edX installation will benefit from such having such built-in mechanism.

I would love it if the i18n-tools became the tool of choice to add such support so it’s not just the edx-platform repository, but all of the Open edX services, XBlocks and Independently Deployable Apps (such as eCommerce) can benefit from.

Let me know if there’s a way I could help to make that happen. I’d appreciate it if you tag me for review whenever there’s a code you’d like to contribute to make such feature available.

We’ve updated a few of our XBlocks to use i18n-tools, including xblock-polls and problem-builder.

Certainly! Will do if it comes to that.

Yup! I’m following that closely and I like what you and your team have done there.

I’m thinking that the i18n-tools should have a mechanism of handling non-upstream strings and translations.

What do you think?

Really sorry for missing this ping and not responding.

I definitely think that’s a good idea. It seems a bit simpler with python translations since those can be moved to a third-party-app and will be loaded just fine during runtime, however the issue I find is with JavaScript translations. I guess they could be moved to a pluggable app as well, and then the static JS translations could be generated as a step during configuration. I have unfortunately not worked with translations enough to know the tradeoffs here.

On a side-note. I’ve realised that a lot of the translations I wanted to submit already exist on Transifex, but are unreviewed. What is the process for reviewing translations? This is something I unfortunately cannot help with since I am not familiar with the language (Arabic in this case). Are new submissions automatically or periodically reviewed?

Hey @xitij2000 sorry for not getting back to you earlier. Arabic language translations is managed by the community like most of the other languages. I mostly ignore the reviewed/unreviewed status for my own purposes.