Update translations/settings-patchmanager.ts file on master should trigger transifex

[b100dian]

This should trigger transifex.

Also there were some strings marked as "vanished" in #53 - My guess is Qt Creator building (I built from commandline). I reverted only the translations/ part of that commit, added back what my commandline build generated, then added the de strings.

Next let's sett if transifex gets updated (it did, on my super secret org)

[nephros]

Also there were some strings marked as "vanished" in #53 - My guess is Qt Creator building (I built from commandline). I reverted only the translations/ part of that commit, added back what my commandline build generated, then added the de strings.

The"vanished" lines appear when lupdate is run, to mark previously translated strings for which the original source string is not found in the source files.

It is safe to keep them in there, usually things like Transifiex should be able to pick them up again should the source strings reappear some time later.

It's quite possible I mangled them locally when compiling, not sure.

[b100dian]

Agreed about the vanished strings but they aren't actually vanished in this case. That's why I assume a different `lupdate` command is run. Look for the "other" category string for example. Today that is not localized on DE because it is marked as vanished.

…

-- Sent from my Sailfish device

[b100dian]

@Olf0 or @nephros - I still need to merge this "unvanishing" strings PR for two reasons:

1. the vanished string are not translated anymore. They are not vanished however, pick one from the diff and see it's still there
2. to see the transifex integration in action for the first time. This would better trigger the translation team.

I will probably follow up with updates like this whenever translations/settings-patchmanager.ts changes (you should include this one in PRs too) and will follow up with more roles on the transifex org, just need this test first. Thanks!

[Olf0]

@Olf0 or @nephros - I still need to merge this "unvanishing" strings PR ...

Sounds like you are indirectly asking for a review.
Well, I tried, but have to admit that I do not understand how the whole Transifex process works at all. Can you point me to some documentation?

1. I also do not understand the addition of all the ../installroot/[...] paths, which can only occur while running rpmbuild, correct?
2. I believe to understand that this pattern (also here) is just an abbreviated syntax, correct?
3. I do not understand, why this block has to go.

Look, apart from shell scripts, spec files (the is only a single one around, here), history, some background knowledge, experience with PM and organisational stuff, my know-how is little to no help, as I originally announced. I can try to comprehend new stuff, though.
And these things do cost time, hence stalling my other little endeavours (searching, finding and submitting the olf-icon, setting up the Openrepos page, setting up the FSO-feedback page), as you also remarked.

Still I would like to understand the Transifex process a bit better, to comprehend how a commit containing enhanced source and target strings can be applied: PR #46
I.e., I could split that MR, but inputting all the enhanced target strings at Transifex manually is a no-go.
Also I do not like altering the source and target TS-files (which have been unchanged for years) before resolving and applying PR #46 (which also has been stalled for years). Can you please help with that, first? It is only string changes.

IMO, there is no reason to rush the topic translations, because there was a standstill for years!

[b100dian]

Thanks for the review @Olf0 - I haven't noticed the installroot paths either, let me see if I can find their cause.

The changes are purely mechanical by lupdate, except "add back de strings" where I was adding back translations Peter already included.
The EN file doesn't seem to be used by the app or by transifex, that's why I didn't bother updating it. I will try to remove it (the non-suffixed file is EN)

[b100dian]

The installroot folder is created by my way of building patchmanager, through a porters script which calls mb2 with CWD set to patchmanager and that creates installroot.

I haven't experience the literal asterisk though - but have not been able to generate .ts files update from Qt Creator, only through the workflow above, which duplicates some file references in installroot

[nephros]

I haven't experience the literal asterisk though - but have not been able to generate .ts files update from Qt Creator, only through the workflow above, which duplicates some file references in installroot

That might be related, from my very brief research about wildcards in pro files there was some mention using them confuses qtcreator somehow.

[b100dian]

Ok, now I also know where the <name></name> vs <name/> comes from.
lupdate on my system is 5.15
mb2 build-shell lupdate is 5.6
The latter was contracting to <name/>

Sounds like manually running lupdate -pro is the way to go?

[Olf0]

Ok, now I also know where the <name></name> vs <name/> comes from. lupdate on my system is 5.15 mb2 build-shell lupdate is 5.6 The latter was contracting to <name/>

Sounds like manually running lupdate -pro is the way to go?

I did not say that this is wrong, only that this is a unexpected change, in contrast what you stated to be altered.

[b100dian]

heads up, I'm reworking this using lupdate/lrelease commands over @nephros's commit

[b100dian]

the two commits where no human edit was made have the commands attached

[Olf0]

While this fixes a lot of broken things, still some new type="vanished" are introduced (where the translated strings are there, in fact), e.g.:

• [nl] https://github.com/sailfishos-patches/patchmanager/pull/66/files#diff-671a7bfce0b1e0466c8ca587f409fcb6335cc1d91412b73cb1edd18a325c57c0R239
• [nl] https://github.com/sailfishos-patches/patchmanager/pull/66/files#diff-671a7bfce0b1e0466c8ca587f409fcb6335cc1d91412b73cb1edd18a325c57c0R466
• [nl_BE] https://github.com/sailfishos-patches/patchmanager/pull/66/files#diff-d15607b0954f57322273c328a093e7bdcacc38325d87804c83478ed69516c291R239
• [nl_BE] https://github.com/sailfishos-patches/patchmanager/pull/66/files#diff-d15607b0954f57322273c328a093e7bdcacc38325d87804c83478ed69516c291R466
• [pl] https://github.com/sailfishos-patches/patchmanager/pull/66/files#diff-9a1a8955cd6b8dab3485b761f60c923035748c38711765f79476b8d7f75d81aaR239

And supposedly many more, if not all of the TS-files, each in lines 239 and 466.

[b100dian]

Thanks Olf for this pass. The vanished you're mentioning seem to be because 'Have possible conflicts' is now 'May have conflicts' and 'Developer mode' is also changed into "Allow incompatible patches".
I'd merge this and will observe tomorrow if the changes (esp. the DE ones) are picked up.

[Olf0]

O.K., there you go.
But now we are really cheating with my "approval"!

[Olf0]

Please also mind that #73 alters more strings, but also simplifies some!
And it is too complicated (code-wise) that I will approve it.
Maybe it would be better to review #73 first and let @nephros merge it, before continuing with this one?

Either way: Please review #73!

[b100dian]

Yes, I'll review that PR tonight.
I am going to merge this to see actual transifex in action, then we can iterate (make one more PR).
Remember, transifex only looks for changes in the translations/settings-patchmanager.ts file as it is configured now (and generates the other languages out of it - let's see!)
I have also added you as Project Lead on transifex. I didn't find a username @nephros to add Peter though.

But now we are really cheating with my "approval"!

No, I think it's part of the learning process, we must more than one person looking for the transifex integration. Consider it part of onboarding - even if this doesn't work as intended, learning it will be either way.

[Olf0]

No, I think it's part of the learning process, we must more than one person looking for the transifex integration.

Well, ack.
Though I am not convinced that I am appropriate for this.