Locales: Finish RU, update DE; fix EN

vadcx commented 4 months ago

Completely update the Russian translation. Including fixes and new strings
More strings translated in German. Few updates/fixes
Only grammar fixes in English locale

Completely untested. Created with Web Extension Translator

Preface: someone in comments on a website that's presumably catering to open-source and FOSS enthusiasts "can someone report this grammar mistake?" ... Well yes, but did you know that magic doesn't happen on its own accord?

I used the WET as per instructions. I see the diff is absolutely massive, because it changed the JSON structure completely. I am not sure if you are

a. OK with this? Because you point out to use git's diffing to see if the source (EN) translation was updated and downstream locales need updates as well b. If this breaks the structure the i18n library you use expects?

Yes, I didn't test this (how would I load a changed locale file along the extension in Firefox?). I hope this runs but as for translation quality, I actually wish and expect for other people pick this up and improve, in wiki style.

I didn't finish German because I've had too much.
As far as Russian goes I am fairly certain of my translation skill and while there are some strings that need double-checking with Firefox' own terminology (glossary), it should be a very close match. I've also adapted some IT terminology like "Addon" -> "Extension" to be easier to comprehend for everyone, since addons are no longer called such anyways. I doubt there will be uproar from the previous translator(s). Even if: point them towards a "Create pull request" button ;)

piroor commented 4 months ago

Please keep the original styling of the en locale and update only messages, because it is very hard for me to confirm details of your changes. Sorry but I can't review and merge this as-is.

vadcx commented 4 months ago

@piroor OK, I understand. I will see if GitLocalize keeps the structure intact. This means that WebExtension Translator cannot be used (it's a recommended way), because it modified the structure itself and added all these fields.

piroor commented 4 months ago

Hmm, GitLocalize breaks styling of JSON so it looks not good to modify en and ja locale with GitLocalize... Entries in those original locales are sorted and grouped with their context, for better development experience for me. I think en and ja locales need to be updated by editing their JSON sources with this repository, until we find out something better way to edit locales keeping their original style.

vadcx commented 4 months ago

I see. Is the grouping strictly manual or is something like sorting by key acceptable? My idea is to see if filtering & sorting with jq would be enough (to remove unnecessary values, sort keys etc.) Yet the current update I'll need to transplant onto current (or jq-ed files) manually. Maybe not English and German, but in the Russian file I've probably touched 1/2 to 3/4ths of strings.

piroor commented 4 months ago

Basically I think entries should corresponds to the order and groupings in uses on the UI: options page, menus, and so on. There are some exceptions by historical reasons and I think they should be rearranged to match to current UI. Sorting based on character codes will break such ordering and grouping, so I think en and ja locales need to be managed fully manually for now.

piroor commented 4 months ago

Changes to locales except en and ja are basically merged as-is (if there is no changes around executable codes) because I can't review translated messages. I think it is better that entries in those locales are also ordered same to en and ja, but currently I prefer to the easiness of translation tasks by contributors.

vadcx commented 4 months ago

My workflow so far (documenting in case someone less tech affine needs to follow):

Undoing the ENGLISH / JAPANESE language file:

Get both files, old and new updated
Run both files through jq to normalize formatting (jq is a streaming JSON processor, so it keeps the ordering intact but formatting will be different): jq "." /path/to/messages.json > messages-jq.json
Now you have old and new normalized files, compare with diff to see the strings you modified: diff messages-old-jq.json messages-new-jq.json
Manually put updates visible through diff into actual original JSON from repo.
Delete the temporary files from above
Submit

Tip: while you are on your own translation branch, you can retrieve the original messages.json from branch trunk with this git command: git show trunk:./messages.json > messages-trunk.json

Undoing other translation files where WET (WebExtension Translator) added its custom fields:

under each translation key there's now a hash
in JSON root there's __WET_LOCALE__

Refer to step 2 above, you only need to change the command slightly to eliminate these keys in output:

jq "del(.[].hash, .__WET_LOCALE__)" messages-new.json > messages-new-jq-cleared.json

Continue with step 3. You can now transplant new changes onto the old file manually as before... or offer piroor a deal:

EDIT: I hit CTRL+Numpad Enter by mistake and it submitted the comment... Please wait while I finish typing duh! I will post a separate comment

vadcx commented 4 months ago

The Deal: piroor, there are 113 changes to the DE translation, 257 to the RU translation. That's too much for me to redo by hand just to keep formatting :/ Technically you could (have someone else) review these changes even with changed formatting with this:

normalize repo's messages.json with jq
normalize translation update .json with jq
diff both files, it should only yield the changed values

Other than that, I am going to commit the files as following:

English messages: updated manually, entire file kept as-is
Russian, German messages: ran through jq once to normalize formatting and remove "hash" entries added by WET. The ordering is kept exactly the same (neither WET nor jq modified it), but the formatting changed to multi-line. There's no way to finely control jq's formatting (either pretty-print or single-line).

PS: If future translators follow the same procedure of WET+jq, they should produce a minimal diff. PPS: I missed the opportunity to produce a minimal diff myself, had I split formatting changes and text updates in two commit here...

This is ready, piroor.

piroor commented 4 months ago

OK, I've wrote a script to merge updates in your translation to the original locale keeping JSON format: https://github.com/piroor/treestyletab/commit/52bc5f294ad154098fe17cbae748fbc4daeaae8a And I've merged changes on this PR manually: https://github.com/piroor/treestyletab/commit/aebfa7dc9dad6b8fa8655c3358ccb729ef058bea

So I close this PR without merging, sorry I couldn't leave your credit as the author of the commit... Anyway thanks a lot!

vadcx commented 4 months ago

Thanks, I don't mind. However git itself allows to specify the commit author (you, because of the new script) and commiter (you too) and then co-authors like this

piroor commented 4 months ago

Oh, I didn't know that, I'll try that at next chance!

And I've realized that there are some more not-translated-yet entries at the commit https://github.com/piroor/treestyletab/commit/aebfa7dc9dad6b8fa8655c3358ccb729ef058bea - they were simply copied from en locale, it is due to a bug of my script. Could you translate them also?

piroor commented 4 months ago

I've confirmed that there are no not-translated-yet entries in ru locale.

vadcx commented 4 months ago

Yes, sorry. I didn't finish the German translation and don't plan to. I will rethink it tomorrow if I have the motivation to dive deeper :)

piroor commented 4 months ago

OK, I'll remove these untranslated entries from de locale if necessary. Don't mind!

piroor / treestyletab

Locales: Finish RU, update DE; fix EN #3549