File Provider Extension Translations Repeatedly Deleted on Transifex

[p-bo]

@i2h3

Hello,
it seems, that uploads of source strings updates (including recent round related to #9413) have repeated unfortunate side effect in form of deletion existing translations too - see for example:

From what seen in strings history, standard procedure trough nextcloud transifex-bot (https://docs.nextcloud.com/server/latest/developer_manual/app_development/translation_setup.html) isn't working in this case, thus alternative (manual?) method directly trough Transifex API was implemented, but has this flaw.

It certainly is possible (as translator) to (manually) recover translations one-by-one from translation memory, but is a bit daunting task to repeat this again and again just to keep it translated till next sync.

Would it be possible to fix this please?

Thanks for all your work :-)

(Perhaps @rakekniven, as Transifex admin, could have some helpful insights here?)

[p-bo]

Remembered the same there: nextcloud/swiftnextcloudui#3 (comment)

[i2h3]

@p-bo It is right that our usual procedure is not possible with Xcode string catalogs (the new standard localization technology for Apple platforms) due to the rudimentary support by Transifex.

For safety, we internally agreed to make this a manual process with an actual review. Also, because there rarely are changes in these software pieces. I manually checked for the correct insertion of new keys and unchanged retention of existing translations (not each of them but some).

Rightfully, at least one translation key and all of its associated translations was removed due to being obsolete.

I cannot understand which specific case you are referring to above in the screenshot. Can you please provide a link or the original key to translate? I cannot find that in the diff of the pull request.

But now I have a hunch of what is wrong: When pulling from Transifex, tx pull --force --all --mode=reviewed --minimum-perc=50 is used. So then Transifex probably leaves out languages which are below the threshold. When pushing the locally updated string catalog back with the new changes, it maybe erases the translations of languages below the threshold. Does that sound plausible? Then the solution would be to not filter by review state or percentage at all. Can you confirm your example refers to a string which was either not reviewed or part of a language with less than 50 percent translation progress?

Sadly, Transifex does not support merging with string catalogs, we have to do it with custom tooling on our end.

[p-bo]

@i2h3 Thanks for your explanation and investigation - appreciated!

I cannot understand which specific case you are referring to above in the screenshot. Can you please provide a link or the original key to translate? I cannot find that in the diff of the pull request.

Original keys from referred example are here:

desktop/shell_integration/MacOSX/NextcloudIntegration/FileProviderUIExt/Localizable.xcstrings

Line 666 in a8bdb4f

"Could not get identifier for item, no shares can be acquired." : {

and

desktop/shell_integration/MacOSX/NextcloudIntegration/FileProviderUIExt/Sharing/ShareTableViewDataSource.swift

Line 111 in a8bdb4f

presentError(String(localized: "Could not get identifier for item, no shares can be acquired."))

But now I have a hunch of what is wrong: When pulling from Transifex, tx pull --force --all --mode=reviewed --minimum-perc=50 is used. So then Transifex probably leaves out languages which are below the threshold. When pushing the locally updated string catalog back with the new changes, it maybe erases the translations of languages below the threshold. Does that sound plausible? Then the solution would be to not filter by review state or percentage at all. Can you confirm your example refers to a string which was either not reviewed or part of a language with less than 50 percent translation progress?

Yes, in case of language in question (Czech - but certainly affected also others) strings weren't in reviewed state, but were fully translated before update (they were lastly again translated 2-3 moths ago). So leaving out --mode=reviewed could help there (must admit I don't comprehend that percent limit necessity too, but respecting it).

Sadly, Transifex does not support merging with string catalogs, we have to do it with custom tooling on our end.

Glad to see you managed to overcome Transifex limitations somehow and are providing way to translated strings at all - thanks :-)