feat: add atlas step to the build - FC-0012 #22
Conversation
Adding the pull behind a feature flag until it's fully implemented Refs: FC-0012 OEP-58
shadinaif
force-pushed
the
shadinaif/FC-0012-OEP-58
branch
from
08ac842
to
0c0000b
Compare
|
please review @regisb @OmarIthawi |
There was a problem hiding this comment.
This change looks good to me, but I'm wondering what's the strategy here. For how many plugins are you planning on deploying atlas behind a feature flag? If Atlas works, then we should just add it to all plugins, with no feature flag. (and make it possible to customize translations) If it doesn't, then surely we don't need more than one or two plugins to realize that, right?
Good point. Atlas currently work and only valid translations are making it to That's a good change since the last time we worked on the tutor-discovery. What we lack now is testing from anyone who's on a recent release which we lack access to. The most recent production/staging release we are working on is on Maple. Nevertheless, I think we can remove the feature flag for credentials and experiment with |
|
I'm glad to hear that Atlas now has translation parity with pre-OEP-58! Before we can enable Atlas by default, I'd like to know the following:
We should try to enable Atlas in time for Quince (Dec. 10th). But if we don't, that's fine too, we can always merge it later.
Yes, we can, but in nightly or quince, not in master. (this PR currently targets the "main" branch) |
Currently only MFE Communication and discovery are fully functional. Others are work in progress.
This use case needs more study. Our goal is at least not break what Tutor have at the moment if the old Transifex project was used. We argue that this use case will be needed less due to the low turnaround time between Transifex and Nevertheless, the edx-platform customization should work regardless of how the translations is being pulled because it uses MFEs customization isn't compatible at the moment with
This is the full list of supported languages: More support will be added in-line with the Transifex Working Groups.
@regisb @shadinaif yes let's use the As for a timeline, we'd like to perform the cutover in January. |
|
It is absolutely essential that users are able to customise the translation strings. We need the following features:
Until we have these features, I propose that we focus on one or two IDAs. I don't see the point of deploying Atlas in all Tutor plugins. Let's integrate Atlas in the nightly branch of one or two plugins. Once the above items are resolved (and we can help with that), we can generalize to other plugins. Does that make sense? |
Makes sense. edx-platform support for customized strings to be retained. No issues with that.
MFEs for overriding languages support can be added, but it needs a bit more work.
Some of the points makes sense, but the timing doesn't. The old Transifex project is planned to be set as read-only after Quince is cut. Same for in-repo strings for all MFEs and Python repositories. So we need to ship those features with or without a flag to prepare for the cutover, otherwise the Tutor nightly and anything after Quince translations will be outdated. To summarize, I still recommend shipping those features behind a flag in nightly as soon as possible to keep Tutor up to date with the Transifex projects changes happening in January 2024 after Quince. Whether we want to ship them without a feature flag and enabled by default is an option we're open to go for if the Tutor teams support that. cc: @brian-smith-tcril for timeline and old languages discussions. |
I understand the urgency. What you are saying is that it's preferable to break existing customization features (in nightly) rather than to have outdated translation strings. I disagree with this approach for the following reason. We are going to open 13 different pull requests (one for each official plugin) to run Atlas there. Then we are going to think about a way for Tutor users to customize their translation strings. After we figure out how to do that, we are going to open 13 new pull requests to implement this mechanism. That's a total of 26 PRs. What I propose instead is that we design a comprehensive extension mechanism right now and try it out on a single repo. Once we are confident we have the right approach, we generalize Atlas to all plugins. And since we know for a fact that Atlas will be in Redwood, there's no need to hide Atlas behind a feature flag at all. How does that sound? If you disagree let's schedule a meeting to talk about this. |
Not necessarily. We can ship most of the plugins work in a backward compatible way. The only thing that's going to break, if we enable another MFE without re-ordering the For all other repositories the overriding the translations feature would be maintained including this Credential My question is, are we open to changing the i18n-merge feature and cleaning up the https://github.com/openedx/openedx-i18n work if we can address the same Developer need, i.e. overriding translations? Back to the feature flags. The reason we're keeping the feature flags is because we'd like to ship the feature disabled by default until the Transifex project cutover, happening in two weeks. What I'm seeing is two options in both this pull request and other open ones:
It appears to me that you're preferring Option 2. I think that's reasonable.
Let's schedule a meeting if we non of the options I've suggested makes sense. |
|
To conclude our discussion, I'm opening other two PRs: |
|
@shadinaif thanks for your work here. As you can see Tutor/Atlas integration has gone pretty off the the original plan and this needs to be closed in favor of #29 @Faraz32123 please close this pull request. Thanks everyone for the feedback. |
|
closing this PR in favor of #29. |
Adding the pull behind a feature flag until it's fully implemented
Background
This contribution is part of the FC-0012 project which is sparked by the Translation Infrastructure update OEP-58.