-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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 Hungarian translation for 1.93–94 #6186
Conversation
I absolutely agree, this is an issue that needs to be addressed... |
First: I'll get an issue started when I get some free time to discuss the best way to coordinate translations for yall. Second: Thank you @smileyhead for an amazing PR. Third: @smileyhead can you tag another hungarian speaker to give this translation a review? It doesn't have to be super thorough for one this big -- we just have a policy that another native speaker takes a look, just to be safe! |
Sure thing, and thanks for the work on making the localisation process better. I will tag @SonoSooS to proofread, but let me just ask: Does every update need to be reviewed by someone else? I am the same person who translated the rest of the app as well, which has been checked and approved, and it's not like the quality of my translations is going to change (or at the very least, it will not worsen). The localisation updating process already seems rather slow as it is. Based on the current timing, this PR would not have made it into the final build even if I translated every new string as soon as possible. |
I would proofread the changes, but judging by the changed line numbers, and the messages in this comment chain, the lines in the translation file got scramled around in order, which means that I'd have to do redundant checking of translations that were not actually changed. I waited 5 minutes at 100% CPU use to try to load the diff, but I have a feeling, that even if it loaded, I'd have to sift through unchanged strings, just because the line order got scrambled around in the file. It took a lot of time to do the initial checking, checking translations in context, interacting with every possible situation to see if everything matches the context, etc., I don't think it's very productive to have to do that every time new strings are added, especially if most changes don't affect unchanged translations, to see if the context of any unchanged translations could be affected or not. So yeah, we definitely need a better method to diff translations, so they could be edited (and checked) easier.
I don't think we should let verifiers compromise the translation. If it's mandatory for verifiers to proofread the translation, then I'd expect them to check it with the same vigor the translator used to make the translation.
In my opinion, there needs to be a trusted/verified translator program, or a trusted hiearchy system of translation writers and verifiers, or something else akin to these. |
(Closing while I translate the new strings for 1.94…) |
Reopening… |
I think there’s no need to close this PR, as it includes additional discussions on improving the translation environment. Opening a new PR might make it harder to track these discussions. It would be simpler to merge the latest main branch into this one and continue building on it. Although it might make the original focus of this PR (Hungarian translation updates) a bit more complex. |
I have reopened the PR already. I only temporarily closed it because GitHub wouldn't let me sync my branch without discarding the previous commits first. |
It’s possible that upstream updates to Hungarian translations (such as run The GitHub web interface’s suggested approach of discarding changes isn’t ideal—it would be better if it guided users to resolve merge conflicts first, similar to how GitHub Desktop handles it. Discarding the previous translation work might slow down progress, especially since the earlier version contained over a hundred translated strings... You might consider rolling back the merge to recover the original translation progress, then resolving the merge conflicts and syncing with the latest main branch. This approach should help reduce the current translation workload. |
This is a good point; before I discovered how to resolve conflicts from a PR I was confused by this and followed what GitHub was telling me to do when I tried to sync the branch and discard the commits, which isn't necessary. GitHub could definitely improve this. |
Same here. Before I figured out how to properly handle merge conflicts, I saw that “discard changes” was the only option available. I assumed I had to discard them to sync with the latest changes, so I chose to discard… This shows how important it is to have a translation platform. Many translators are great at translating, but handling GitHub errors can be difficult for them. It would be better if they could focus on what they’re good at part. |
No progress has been lost. I've made a copy of the Hungarian .po file from the original PR beforehand and applied the 1.94 changes to it. From GitHub's perspective, nothing should be different than if it just let me sync without losing changes to the .po file. |
So…will this get merged before the release of 1.94? If not, the localisation will be two updates behind. |
I'm sorry, no. I merge translations right before cutting a release. I know there's some frustration about the coordination here. It's probably time to formalize this process and get better contact with our translators!
I think we do need to get crowdin going so that we can formalize this. I'm sorry this won't be as fast as yall deserve. We're putting out a lot of fires! But I've got this high on my task list. FWIW this is informally how it's done. I have a document where I track this, but I also do it by memory. Somebody like quiple has no-verification approval, after a long contribution history. @smileyhead since this is your second contribution I would still normally still want review, but I also don't want to slow you down more so I'm going to go ahead and merge. I'm sorry about frustrations with this; I don't want yall to ever feel undervalued. Our somewhat informal translations process was adequate until things popped off this past week, which of course meant that lots of things needed attention all at once. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And of course: TYSM
I have updated the Hungarian localisation for 1.93.
I also have some feedback:
I would like to reiterate my question from the original PR: Is there a way to be notified when modifications are made to the strings? Since my last update, 113 strings were modified or added, none of which I was able to translate in time before the build was published. With all due respect, I would like to avoid making a habit of having to check for new strings each and every day, lest a new version be made public with an unfinished translation.
I wonder if moving the translation efforts to a service like Crowdin could be done? That way, the system itself would be able to send out notifications about newly-added strings. I believe they have a free tier for open-source projects.