-
-
Notifications
You must be signed in to change notification settings - Fork 166
Update the webwork2.pot file. #1669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the webwork2.pot file. #1669
Conversation
|
Should we go ahead and merge this to get this started? We can then announce to translators. |
|
Yeah, I think that would be good. |
|
I have a new plan with this (and other pull requests) to keep the release candidate branch and develop in sync better. I re-targeted this to the release candidate, and the plan is to merge the release candidate branch into develop when this is merged. I will do this as all pull requests that are merged into the release candidate branch. Things that go into develop that will not be part of the release of course will not go the other way (if there ever are any of these). I have made the version bump pull requests draft pull requests, and we will merge those last. So for the most part the develop branch and the release candidate branch will be synonymous. This resolves issues with how the Transifex setup works. It is debatable though if the "release candidate branch" is even a good idea. One issue that could occur is if strings are changed in the develop branch for a pull request that is not intended to go into the release. Those strings will be pulled in by Transifex, and shouldn't be. So it may be better to just use the develop branch as the release candidate, and defer pull requests that are not for the release until after the release. |
579a329 to
a7c42f1
Compare
If I understand correctly with transifex, a commit to |
|
It is messy to change the branch that Transifex pulls from. It is designed to be set to one branch, and left that way. To change the branch you have to delete the current Github integration, and set it up all over again. |
|
I guess the real problem is that nothing is really set up to use git branches for releases the way that we do. That includes Github. |
|
If we are deliberate in only updating |
|
That is correct. So what we do is just run the script using the release candidate branch, and then push that result into develop. |
a7c42f1 to
516b2fa
Compare
|
As it seems that 2.17 is pretty much finalized in terms of major change - I would it is appropriate to merge this and enable working on the translations. However, if there are any remaining PRs which change the collection of phrases which are intended to be completed and merged into 2.17, I would hold off until they are completed. Sorry, but I am not up-to-date about the current plans for closing off additional major changes for the release. |
|
I think the major changes to translations are all in. I think in any case, it would be good to get this in. |
|
So now all new strings are in Transifex. Before the final release we will need to push the updated translations back to here. So hopefully translators go to work now! |
|
Is there a good way to let people know? Do we have a contact list? Should we ask Mariana with help on this? |
|
Putting a comment here is not a way to let translators know. We need to find a good way to do that. |
|
Our main methods of communication with the community are the forums, the new website (openwebwork.org), and the mailing list that Marianna is maintaining. Do we have documentation on how to use Transifex? We should put together an announcement, then I can work on getting it distributed. |
|
I think that for the most part the usage of Transifex for translators is straightforward. They need to create an account there, and then they can edit the strings directly in the Transifex web interface. Although, I admit that I haven't done much with that. @taniwallach will probably have better information on this. |
|
Working in the Transifex web interface was pretty easy to figure out from what I recall. I think people can apply to join the translation team and then someone with suitable permissions needs to grant them access (at a suitable level). About contacting translators - the only idea I have would be to reach out to people who either edited in Transifex in the past and those who made pull requests with translation code directly to GitHub. @mgage may also have some recollection of who else worked on translations. |
Once this is merged all current strings will be updated to Transifex. Then we need to work on finding more translators.
Note that this needs to go into develop since that is the branch that Transifex updates from. A copy will then need to also go into the new release candidate branch.