Sending strings from frontend-app-communications to Transifex

[antoviaque]

Contributor meetup topic imported from https://openedx.atlassian.net/wiki/spaces/COMM/pages/3934289923/2023-11-28+CC+Working+Group+Meeting+Notes

How do we make sure strings in frontend-app-communications are sent to Transifex?

• Presenter: @sambapete
• Notes from previous meetings:
  • Not fully discussed during the previous meeting as Pierre Mailhot was not present, but the topic was brought up in Slack.
  • There seemed to be a blocker on the availability of Atlas for Quince, but it now seem available: feat: use atlas in make pull_translations on palm FC-0012 frontend-app-communications#156
  • Strings are sent to Transifex, to the Open edX translation project, will be used by Atlas from Quince (maybe, as some of the changes were made after the cut for Quince).
  • Is MFE translation support production ready? Yes, since Olive.
  • Not sure this has been tested by the BTR group. Not sure if it’s on the BTR backlog, but there is some issues items on the MFE projects
  • You have to translate in both the edx-platform and openedx projects, risks of sync issues between the two projects - question for David and Omar to know when Atlas will be put in place. Will require some setup to transition between the two.
  • For Pierre, not an issue for Quince for him, as he has a hack, but could be for anybody else not using English. This workaround could be communicated with others, but might require access to be granted by Eden & Omar.
  • Quality control issue about MFEs being put into production
• Action items:
  • @jalondonot will be bringing it up with the BTR group and ask @OmarIthawi
  • @sambapete to see with the BTR group and @peter Pinch about posting a warning about this in the release notes, and give a workarounds: use the JSON file of the translations, and use it with the feature in Tutor to override the language files

[OmarIthawi]

@antoviaque @jalondonot would you mind posting an issue somewhere so we can tackle the bug?

I'd like to know more about the problem you're facing. As of now, Quince supports atlas for the Communications MFE without hacks. If we missed anything, please let us know about the bug to fix it.

[antoviaque]

@OmarIthawi I don't know if there is another ticket for this bug already - @sambapete might be able to better answer that, since he brought up the issue for discussion.

[sambapete]

Unfortunately, because of upcoming changes in our organization to be announced soon, I won't be able to follow up on this.

…

On Tue, Jan 2, 2024, 10:16 Xavier Antoviaque ***@***.***> wrote: @OmarIthawi <https://github.com/OmarIthawi> I don't know if there is another ticket for this bug already - @sambapete <https://github.com/sambapete> might be able to better answer that, since he brought up the issue for discussion. — Reply to this email directly, view it on GitHub <#107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD6PLKI3X26LSBDVU47AV3YMQQFVAVCNFSM6AAAAABBJC4SBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUGE2TOMJQGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sambapete]

One thing I might point out, and that might be the biggest problem right now, is that not all translators have access to frontend-app-communications strings in Transifex at this point thus making it difficult to use by operators who didn't have access like I did for fr_CA. Unless this has changed very recently but I haven't checked since early December 2023. I agree with @omar Al-Ithawi ***@***.***> that it might work for fr_CA but maybe not for other languages because the strings have not been translated yet.

…

On Tue, Jan 2, 2024, 11:28 Pierre Mailhot ***@***.***> wrote: Unfortunately, because of upcoming changes in our organization to be announced soon, I won't be able to follow up on this. On Tue, Jan 2, 2024, 10:16 Xavier Antoviaque ***@***.***> wrote: > @OmarIthawi <https://github.com/OmarIthawi> I don't know if there is > another ticket for this bug already - @sambapete > <https://github.com/sambapete> might be able to better answer that, > since he brought up the issue for discussion. > > — > Reply to this email directly, view it on GitHub > <#107 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACD6PLKI3X26LSBDVU47AV3YMQQFVAVCNFSM6AAAAABBJC4SBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUGE2TOMJQGQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[OmarIthawi]

Makes sense @sambapete. We'll not tag you again for this.

Hopefully, we get to work with you in another way.

Thanks again @sambapete for all of your hard work and contributions.

[antoviaque]

Thanks @sambapete - and sorry to see you go :(

@OmarIthawi does @sambapete 's answer help answering your question? We could treat the current ticket as the bug report.

[OmarIthawi]

The strings are already in Transifex, however most translators aren't using the project:

• https://app.transifex.com/open-edx/openedx-translations/content/

We're cutting off the old project and we'll be using the new one, so it'll be good. I don't think this is a bug anymore but I'm happy to be shown a more specific bug report.

[antoviaque]

@OmarIthawi I'm not fully familiar with the issue so it's hard for me to answer, but I think I remember Pierre mentioning that few of the translators had access to the new Transifex project - do you know if that's still the case? And would all strings in all MFEs and all languages appear in the release if they are done there?

@ehuthmacher I think you are the chair of the Translation working group, right? Do you know if there are outstanding issues on your side with MFE translations?

[jalondonot]

09/01 Contributor Meetup Update:

• @jalondonot will invite @ehuthmacher to the redwood.1 release planning session.

[ehuthmacher]

@antoviaque The majority of our translators & reviewers are working on the edx-platform project only and that is still the case. Only a handful of translators have been added to the openedx-translations project for testing purposes. We have not fully transitioned our efforts over to the openedx-translations project, as we were waiting for OEP-58 to be completed. @OmarIthawi @brian-smith-tcril what are your thoughts regarding the transition to the new project?

[antoviaque]

@ehuthmacher @OmarIthawi @brian-smith-tcril What would be required exactly to transition to the new project? Only provide access to all the current translators, or is there anything else? For providing access - do we have a list of all the translators who should be given access? And who has the right to do this?

[ehuthmacher]

@antoviaque I was informed by @OmarIthawi not to fully transition to the new project until OEP-58 is finalized. We are waiting to hear back regarding the timing guidelines. We have a TX WG meeting tomorrow, in which we hope to discuss the timing details with @OmarIthawi and @brian-smith-tcril. Once the transition takes place, we will be leveraging translation memory in TX to ensure that previously translated content is captured to minimize duplication of effort and @brian-smith-tcril will have to facilitate user access. Even though I am an admin in TX, I am not able to provide permissions to users in the openedx-translations project for some reason. I do have the ability to assign access in the current edx-platform project.

[antoviaque]

@ehuthmacher Thanks for the details! Looking at the summary of the last translation meeting, it looks like the cutover has now been decided, right? CC @OmarIthawi @brian-smith-tcril

The group is transitioning translations from the edX platform project to the Open edX translations project on Transifex. They will run one last sync script and then announce the transition.

https://otter.ai/u/j4EiVtSiHU1gTxIJG73PV1efFio?tab=summary

[OmarIthawi]

Yes, the cutover has been decided and done. I think we should close this issue as done. Bug reports are welcome!

[antoviaque]

@OmarIthawi Great to hear! 👍