fllp commented 6 years ago

There are currently three project languages for German:
German (Germany), German (Austria) and German (de).
This is unnecessary and having only one tranlsation (German (de)) should be considered:

for one, there is no such distinction in the official SFOS translations
also, it is unclear which version will end up in Patchmanager: How does the App determine the locale variant to be used once installed?
And: In the worst case, this 'split' triples efforts for updating or improving translations

CODeRUS commented 6 years ago

It's up to users to request languages for translation and translate it. system language is used. My best guess it's a de_de one.

fllp commented 5 years ago

Would it not be reasonable to remove Austria and Germany then? As said, this clutters the translations. And if I understand it correctly, there is no way to switch to those custom languages right now.

nephros commented 2 years ago

52 should resolve this. Closing.

Olf0 commented 2 years ago

Well, there are more to handle: https://github.com/sailfishos-patches/patchmanager/pull/46#issuecomment-933027718

b100dian commented 2 years ago

I've updated transifex with removal of ca, de_AT, de_DE, en_FI, it, ja. I don't know yet how to handle e.g. moving fr_FR to fr (L.E: it's manual and might lose collaborators: https://docs.transifex.com/projects/adding-and-removing-project-languages/#changing-a-target-language ).

Olf0 commented 2 years ago

I've updated transifex with removal of ca, de_AT, de_DE, en_FI, it, ja.

Thanks!

I don't know yet how to handle e.g. moving fr_FR to fr (L.E: it's manual and might lose collaborators: https://docs.transifex.com/projects/adding-and-removing-project-languages/#changing-a-target-language ).

Well, the guide you linked to (but the jump target does not seem to work) describes the manual process very well (including "Do's" and "Dont's"). Mind that the empty fr might have to be deleted first, before

Copy fr_FR over to fr (with no strings, currently) and delete fr_FR.

These few steps also shall be applied to

Move pt_BR to pt (which does not exist, currently).

Plus:

Just use nl, delete nl_BE (both seem to be at the same level).

Just use fi, delete fi-FI (which has less strings translated).

Just use sl, delete sl_SL (both seem to be at the same level).

And:

Delete src/qml/settings-patchmanager.ts

If we do not clean up this mess, now that we seem to have understood it, it will continue to cause confusion and additional, unnecessary research and work (for us or others) in the future.

I believe for a project with only a few strings like Patchmanager, locale specific localisation is much too detailed:

All these would have to be maintained, but translators are scarce.
All these have to be handled technically, which is no issue as long as the automatisms work fine, but becomes one, when they do not.
The likeliness of translations becoming stale rises a lot with locale specific translations.

So let us please create a rule, "Only top level language localisations for Patchmanager". IMO, delimiting the set of target languages is really better here!

nephros commented 2 years ago

Let me tack on another question about the workflow:

As a dev who changes stuff in the source files and prepares a commit/PR:

When do I run lupdate, and do I run it as: lupdate -pro patchmanger.pro -ts translations/settings-patchmanager.ts for just the source file
or
lupdate -pro patchmanger.pro which will change all the -LANG.ts files as well?
Do I include the changes in every commit, as a separate commit per-PR, or not at all?
Because I imagine updating often may cause a lot of unnecessary merge conflicts in the ts files while PRs or branches are worked on. (And they clutter the files-changed/review tab).

Perhaps the best strategy would actually to only update ts files against master, and only after a merge to master as a separate commit (or even automated somehow). Or even more radically, only care about ts files after a tag is added (so, close to release), and not update them at all during regular code changes.

I'm doing that strategy with ThemeColor, where RC tags are presented to the translators two weeks or so before a planned release, and then a x.0 release is published with whatever translations are there - if some come later, I do x.1, x.2... versions with just the language updates.

b100dian commented 2 years ago

I've continued deleting fr_FR and pt_BR, adding fr and pt instead (+Invited collaborators for the latter). The nl vs nl_BE seem to differ ("Pleister" vs "Plakker: all over, plus others) - ~delaying decision a bit~ - actually removed as there were no members in nl_BE. Also fi and fi_FI differ, but the latter does not have members, and its less translated, so gone it is (I have backups). sl vs sl_SL was simple, they were the same, same member, and differing only in 1 string missing in sl_SL. @Olf0 you accidentally zh_CN, shouldn't that be zh?

Also I've uploaded the de translation from the repo (since it didn't show up after integrating the strings - so it seems this is one-way, transifex=>github for non source-language, and github=>transifex for the source-language)

So this leaves us with the next steps to make the same clean-up in the git repo (src/qml/settings-patchmanager.ts but also translations/settings-patchmanager-en.ts which is not used?)

@nephros

* When do I run lupdate, and do I run it as:
  `lupdate -pro patchmanger.pro -ts translations/settings-patchmanager.ts` for just the source file
  or
  `lupdate -pro patchmanger.pro` which will change all the -LANG.ts files as well?

The first one. I think it was not clear to me either on the first update. lupdate -pro patchmanger.pro -ts translations/settings-patchmanager.ts

* Do I include the changes in every commit, as a separate commit per-PR, or not at all?
  Because I imagine updating often may cause a lot of unnecessary merge conflicts in the ts files while PRs or branches are worked on. (And they clutter the files-changed/review tab).

I'd say (from now on) - "none at all" - and we make a separate PR when things stabilize towards a release.

Olf0 commented 2 years ago

I've continued deleting fr_FR and pt_BR, adding fr and pt instead (+Invited collaborators for the latter).

Thanks, especially for having the idea to invite the extant collaborators.

The nl vs nl_BE seem to differ ("Pleister" vs "Plakker: all over, plus others)

Yes, I know; but from my point of view the differences between written Dutch (nl_NL) and written Flemish (nl_BE) are negligible and all Flemish people are used to read Dutch. See, e.g. https://www.youtube.com/watch?v=VrmdY5eQUBw (the first 40 seconds or 6 minutes or full video of ~ 18 minutes). Or (the same guy) even shorter here: https://www.youtube.com/watch?v=Os5HSEqW88I First 20 seconds or whole 11 minutes.

~delaying decision a bit~ - actually removed as there were no members in nl_BE.

:+1:

Also fi and fi_FI differ, but the latter does not have members, and its less translated, so gone it is (I have backups).

Well, we have git any way: We always can look back.

sl vs sl_SL was simple, they were the same, same member, and differing only in 1 string missing in sl_SL.

:+1:

@Olf0 you accidentally zh_CN, shouldn't that be zh?

Well, there is a verb missing, but you are right: I missed that! Maybe my mind suppressed this one, because it is politically and technically the most loaded one: See the first three of the of the answers (not counting the indented comments) here https://stackoverflow.com/questions/4892372/language-codes-for-simplified-chinese-and-traditional-chinese So zh_CN = (formally, correct) zh_HANS = "Simplified Chinese / Simplified Han language" as used in "the Peoples Republic of China (PRC)", which is synonym to (geographically) "mainland China" and zh_TW = (formally, correct) zh_HANT = "Traditional Chinese / Traditional Han language" as used in "Republic of China (ROC)", which is synonym to (geographically) Taiwan.

It is the only one case of languages with a common prefix (zh) I am aware of, where linguists actually agree that they have developed into different languages over the past 120 years, but most significantly since 1949 (i.e., since the manifestation of the political split: See "the Kuomintang / Chiang Kai-shek / White terror versus the Chinese Communist Party / Mao Zedong / Red terror" story, in a brief form here https://en.wikipedia.org/wiki/Taiwan#Republic_of_China_(1945%E2%80%931949) and in details in the Wikipedia pages linked there.

Back to your question, "Shouldn't zh_CN be zh?": I still would answer that with a bold YES, because

"Simplified Chinese" is usually well understood by "Traditional Chinese" speakers, even though some will not like to read it (emotionally / politically).
We have no translator for "Traditional Chinese".
"Traditional Chinese" will not necessarily / easily be understood by "Simplified Chinese" speakers.
The "Simplified Chinese" speakers outnumber the "Traditional Chinese" speakers by a factor of ~ 50.
We want to keep things simple for us.
IMO Patchmanager should not care too much about politics.

And zh is usually handled as equivalent to zh_CN = zh_HANS, so we are doing the (technically) correct thing by renameing zh_CN to zh.

Also I've uploaded the de translation from the repo (since it didn't show up after integrating the strings - so it seems this is one-way, transifex=>github for non source-language, and github=>transifex for the source-language)

O.K.; I will take a look at it at Transifex (or @nephros?), and also the changes to other translations I proposed years ago, when your clean-up work has settled a bit.

So this leaves us with the next steps to make the same clean-up in the git repo (src/qml/settings-patchmanager.ts but also translations/settings-patchmanager-en.ts which is not used?)

Ack; yes, I think so.

Ah, you did all this work only at Transifex so far!?! I have been searching for branches in this and your Github-repo and found nothing: I will look at it on Transifex this weekend.

b100dian commented 2 years ago

Really thorough answer, sorry for triggering you to invest in a such lengthy research - but very interesting in the end!

Ah, you did all this work only at Transifex so far!?!

Yes, only on transifex. The idea is that we can touch up the files in the repo later: e.g. when fr comes in, we amend the transifex PR with deletion of fr_FR. (We can do it before of course, I just spent enough time yesterday only on transifex to do it at once)

Olf0 commented 2 years ago

@b100dian, I moved zh_CN to zh, but fail to invite the extant collaborarators (see bottom of https://www.transifex.com/coderus/teams/56706/zh_CN/ ) per https://www.transifex.com/coderus/patchmanager3/settings/maintainers/ to https://www.transifex.com/coderus/patchmanager3/language/zh/

b100dian commented 2 years ago

I got it

b100dian commented 2 years ago

For reference, I used this button in the header of the bottom list. Project Maintainer should have the ability to invite users per https://docs.transifex.com/teams/understanding-user-roles/#teams-&-collaboration

Olf0 commented 2 years ago

Really thorough answer, sorry for triggering you to invest in a such lengthy research - but very interesting in the end!

Glad you liked it! (There was no research of content, just of links.)

Ah, you did all this work only at Transifex so far!?!

Yes, only on transifex.

https://www.transifex.com/coderus/patchmanager3/languages/

The idea is that we can touch up the files in the repo later: e.g. when fr comes in, we amend the transifex PR with deletion of fr_FR. (We can do it before of course, I just spent enough time yesterday only on transifex to do it at once)

I understand that coding feels different, but having infrastructure (translations, guidance etc.) ready is equally important, IMO.

Olf0 commented 2 years ago

For reference, I used this button in the header of the bottom list.

AFAICS one needs to be Team Manager for that.

Project Maintainer should have the ability to invite users per https://docs.transifex.com/teams/understanding-user-roles/#teams-&-collaboration

No. Project Maintainers can only "Assign new project maintainers" per documentation and in real life; or I have not found the correct place: But the one you pointed to does not allow me to do anything (just look at the list) and the one I pointed to allows me to add new project maintainers.

Can you please also put me in the role "Team Manager" or just invite these three guys to zh?

Olf0 commented 2 years ago

Broken again by the addition of sk_SK: https://github.com/sailfishos-patches/patchmanager/pull/97

Olf0 commented 2 years ago

Broken again by the addition of sk_SK: #97

Fixed per PR #99.

Olf0 commented 2 years ago

I think the language files are "clean" at Transifex now, i.e., only the ones exist, which should.

So this leaves us with the next steps to make the same clean-up in the git repo, plus deleting src/qml/settings-patchmanager.ts (and also translations/settings-patchmanager-en.ts which is not used?)

I am not asking to do this right away, but will try to go over the remaining points of PR #46 next week. But I think we should address this after that (i.e., when I an finished) in order to get the whole TS-story finally done?

nephros commented 2 years ago

So this leaves us with the next steps to make the same clean-up in the git repo, plus deleting src/qml/settings-patchmanager.ts (and also translations/settings-patchmanager-en.ts which is not used?)

I'm not sure about removing the -en.ts one. Formally, the settings-patchmanager.ts file can contain any source language (it's only by convention that English is mostly used), and -en.ts should contain proper English translations.
This is reflected in the fact that settings-patchmanager.ts has no language code in its header so even if you build a .qm file from it it (I think) won't be consulted for English l10n.

And from a brief look settings-patchmanager-en.ts actually does contain some translations even if all of them are just the same as the source strings.

-en.ts can also be utilized (as I suggested elsewhere) to improve the English strings without having to muck about with the source strings - which causes load on the translators and translation commits later which in some cases is unnecessary.

Olf0 commented 2 years ago

So this leaves us with the next steps to make the same clean-up in the git repo, plus deleting src/qml/settings-patchmanager.ts (and also translations/settings-patchmanager-en.ts which is not used?)

I'm not sure about removing the -en.ts one. Formally, the settings-patchmanager.ts file can contain any source language (it's only by convention that English is mostly used), and -en.ts should contain proper English translations. This is reflected in the fact that settings-patchmanager.ts has no language code in its header so even if you build a .qm file from it it (I think) won't be consulted for English l10n.

Ack, but ...

And from a brief look settings-patchmanager-en.ts actually does contain some translations even if all of them are just the same as the source strings.

-en.ts can also be utilized (as I suggested elsewhere) to improve the English strings without having to muck about with the source strings - which causes load on the translators and translation commits later which in some cases is unnecessary.

Yes, but it is not utilised at Transifex, i.e. English is not a language translated!

And I am addressing this exactly to have this discussion, before taking action: Should it go or not? IMO it should.

b100dian commented 2 years ago

even if all of them are just the source strings

This sounds like we can add it back if we actually need to not modify the strings for some reason.

While I agree with the fact that this is just an arbitrary language, the practical case is that we are going to have to update it in git manually (just as the source translation is) every time, or we might [even] have surprises.

Olf0 commented 2 years ago

Done, see PR #108.

Olf0 commented 2 years ago

Because the source file is outdated, I read the documentation on how to update it: https://docs.transifex.com/projects/updating-content/#automatically-updating-source-files I wonder, if we should enable the automatic update of it?

This time I manually updated it, but what are your preferences? I am undecided, because "I do not like automatisms, they might turn against you" and the documentation softly warns: If the source file would be accidentially emptied, then that automatically triggers the deletion of all translated strings! But OTOH, we have a "backup" of the translated files at GH, as long as we do not also automate their download from Transifex. @b100dian might correctly point out that this extremely unlikely to happen. And I am undecided (and not softly against it), because I like the idea of the translation process being more decoupled from our work at GH and this is one step less to care / think about. Likely this decision depends on your opinion, @nephros

P.S.: I am having issues when manually uploading the source TS-file per Firefox 78 ESR. Hence I am more inclined to command Transifex to auto-update from https://raw.githubusercontent.com/sailfishos-patches/patchmanager/master/translations/settings-patchmanager.ts

P.P.S: I am getting this strange warning when uploading that TS-file (when auto-updating no one would see this):

English pluralized strings should contain 2 plurals. Instead, on string '.
.
.
.
.
.
.
' we found 1

What does that mean? Is it relevant?

Olf0 commented 2 years ago

I failed to upload the source TS-file in about 30 tries with Firefox 78ESR and Chromium (which was worse than Firefox to my surprise). @b100dian & @nephros: Can one of you please do a curl -LO https://raw.githubusercontent.com/sailfishos-patches/patchmanager/master/translations/settings-patchmanager.ts and then upload this file under "Resources" with the button "Update source file" at the top to the right.

nephros commented 2 years ago

P.P.S: I am getting this strange warning when uploading that TS-file (when auto-updating no one would see this):
English pluralized strings should contain 2 plurals. Instead, on string '.
' we found 1
What does that mean? Is it relevant?

That comes from https://github.com/sailfishos-patches/patchmanager/blob/master/src/qml/PatchManagerPage.qml#L484 but I'm not sure what it means either. the docs say this is how it's done.

nephros commented 2 years ago

I failed to upload the source TS-file in about 30 tries with FF78ESR and Chromium (which was worse to my surprise). @b100dian & @nephros: Can one of you please do curl -LO https://raw.githubusercontent.com/sailfishos-patches/patchmanager/master/translations/settings-patchmanager.ts and then upload this file under "Resources" with the button "Update source file" at the top to the right.

Tried it, got the same result. Error message about the plural thing.
So I manually removed the section containing that string in the .ts file, and voila! upload worked.

So please continue with the new updated source strings on Transifex, and I'll try to figure out what's so bad about that pluralized source string.

nephros commented 2 years ago

So please continue with the new updated source strings on Transifex, and I'll try to figure out what's so bad about that pluralized source string.

Aha! https://github.com/Sigil-Ebook/Sigil/blob/master/docs/Translating.md

Now manually edit the resulting base.ts file and change all of the following single numerusform tags: to be double empty numerusform tags as follows: <numerusform></numerusform><numerusform></numerusform> so that our base.ts file will work with the much older tools used on the Transifex site.

So, I have done this change, double "numerusform" tags, and Transifex did eat the update now. Anyway, I'll probably remove that fancy plural form thing from the sources if it causes such problems.

Olf0 commented 2 years ago

I failed to upload the source TS-file in about 30 tries with FF78ESR and Chromium (which was worse to my surprise). @b100dian & @nephros: Can one of you please do curl -LO https://raw.githubusercontent.com/sailfishos-patches/patchmanager/master/translations/settings-patchmanager.ts and then upload this file under "Resources" with the button "Update source file" at the top to the right.

Tried it, got the same result. Error message about the plural thing. So I manually removed the section containing that string in the .ts file, and voila! upload worked.

Thank you very much. BTW, my main issue with uploading this file was not that error message: It took quite some additional disabling of NoScript filters (compared to just have the regular functionality of Transifex working) and still it did not work most of the time. Even when I completely disabled NoScript, rarely the upload succeded (just to see that error message, when it did). And with Chromium the menu on the right side was not displayed at all, no matter what I tried; usually Chromium works better for such "modern" web-services thickets, as the one Transifex (Atlassian) created here, as Chrome seems to be the primary (or "only") browser web-services programmers test with.

So please continue with the new updated source strings on Transifex, and I'll try to figure out what's so bad about that pluralized source string.

Thank you for taking care of this issue. So I will continue with what I originally intended to do, when I started with that two days ago.

P.P.S: I am getting this strange warning when uploading that TS-file (when auto-updating no one would see this):
English pluralized strings should contain 2 plurals. Instead, on string '.
' we found 1
What does that mean? Is it relevant?
That comes from https://github.com/sailfishos-patches/patchmanager/blob/master/src/qml/PatchManagerPage.qml#L484 but I'm not sure what it means either. the docs say this is how it's done.

Thanks for the analysis.

nephros commented 2 years ago

Thank you for taking care of this issue. So I will comtinue with what I originally intendend to do, when I started with that two days ago.
P.P.S: I am getting this strange warning when uploading that TS-file (when auto-updating no one would see this):
English pluralized strings should contain 2 plurals. Instead, on string '.
' we found 1
What does that mean? Is it relevant?
That comes from https://github.com/sailfishos-patches/patchmanager/blob/master/src/qml/PatchManagerPage.qml#L484 but I'm not sure what it means either. the docs say this is how it's done.
Thanks for the analysis.

You may want to consider merging this, https://github.com/nephros/patchmanager/tree/l10n-fix, I removed the fancy plural use and separate it into two strings, so we don't run into that issue again.

Olf0 commented 2 years ago

You may want to consider merging this, https://github.com/nephros/patchmanager/tree/l10n-fix, I removed the fancy plural use and separate it into two strings, so we don't run into that issue again.

Even though I wondered, why you did not pose this PR, I went on my way doing this: https://github.com/sailfishos-patches/patchmanager/pull/116 But then I came up with an enhancement, hence I had to contribute to your repo first: https://github.com/nephros/patchmanager/pull/1/files

So this has become a little complicated:

Please merge my PR https://github.com/nephros/patchmanager/pull/1
Then pose your PR here.
As I already have reviewed your PR, I will mark that as reviewed as soon I can.
If you want me to merge it right away, please denote that.

P.S.: This is why I believe we should still make small changes here in the principal code repository (i.e., here), not our own ones: This allows us all to easily add commits directly to it.

Olf0 commented 2 years ago

@nephros, thank you for uploading the reworked TS source file. (I tried that, failed again, then looked at the timestamps, only to realise that you have been quite quick in uploading it after I merged #117.)

That brings us back to my original question (which was the start of a lengthy detour): I wonder, if we should enable the automatic update of it?

Due to me having issues with uploading the TS source file repeatedly, I now unambiguously vote with "Yes"! If another "Yes" vote is cast, I will happily employ this change at Transifex's settings.

Olf0 commented 2 years ago

Do note the excursion with documentation and decisions at https://github.com/sailfishos-patches/patchmanager/pull/145#issuecomment-960222739 ff.!

Olf0 commented 2 years ago

Oh, I was about to close this issue, but one thing is left to do, as the documentation label added by nephros correctly indicates:

Document the decision to accept only primary languages, plus aforementioned excursion with documentation and decisions at https://github.com/sailfishos-patches/patchmanager/pull/145#issuecomment-960222739 ff. in Patchmanager's Wiki section for Translations ("i18n", "l10n").

sailfishos-patches / patchmanager

i18n / l10n: Document the decision to accept only primary languages etc. #27

52 should resolve this. Closing.