Update Hungarian translation for 1.93–94

[smileyhead]

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.

[auroursa]

I absolutely agree, this is an issue that needs to be addressed...

[pfrazee]

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!

[smileyhead]

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.

[SonoSooS]

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.
Don't get me wrong, even if only one string changes in a group of strings, I'd still have to check it for contextual consistency, but it's still much less work than having to redundantly check every little option again where nothing has changed.
I'm not whinging, I'm more than happy to proof-read the translations, but the lost hours do add up.

can you tag another hungarian speaker to give this translation a review? It doesn't have to be super thorough for one this big

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.

we just have a policy that another native speaker takes a look, just to be safe!

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.
With the trusted/verified translator program, trusted/verified translators would have their translations merged as soon as they are done, so users will get the new features seamlessly translated by the time they are pushed to prod.
As for the hierarchy system, there could be a "language manager" (project manager for the given language) possibly doing translation work, and also verifying, and there could be higher level verifiers who could possibly overwrite the decisions of lower-level translators and verifiers (as long as it's not too contended).
As the project grows, it will be just more and more difficult and tedious to get the "supply chain" of the translations rolling smooth, so it's probably better to get good systems in place as soon as we can.

[smileyhead]

(Closing while I translate the new strings for 1.94…)

[smileyhead]

Reopening…

[auroursa]

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.

[smileyhead]

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.

[auroursa]

It’s possible that upstream updates to Hungarian translations (such as run intl:extract for all languages in preparation for a release) caused conflicts with your existing translation branch.

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.

[surfdude29]

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.

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.

[auroursa]

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.

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.

[smileyhead]

You might consider rolling back the merge to recover the original translation progress

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.

[smileyhead]

So…will this get merged before the release of 1.94? If not, the localisation will be two updates behind.

[pfrazee]

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!

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.

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.

[pfrazee]

And of course: TYSM