Core CI start failing in apiTranslation suite

[amrita-shrestha]

Core CI start failing in apTranslation suite (translation.feature file)

• features/apiTranslation/translation.feature:24
• features/apiTranslation/translation.feature:28

https://drone.owncloud.com/owncloud/core/35125/82/13

        Failed asserting that two strings are equal.
        --- Expected
        +++ Actual
        @@ @@
        -'Mauvais ID de partage, le partage n'existe pas'
        +'Wrong share ID, share doesn't exist'

From git bisect it found that 848088e is the first bad commit

[saw-jan]

Test failed for fr_FR language.

      | new         | fr-FR    |
        Unexpected OCS status message :"Wrong share ID, share doesn't exist" in response
        Failed asserting that two strings are equal.
        --- Expected
        +++ Actual
        @@ @@
        -'Mauvais ID de partage, le partage n'existe pas'
        +'Wrong share ID, share doesn't exist'

[saw-jan]

Fixed by new transifex commit?

[kiranparajuli589]

acceptance tests only run for PRs and tags.

"trigger": {
    "ref": [
        "refs/pull/**",
        "refs/tags/**",
    ],
},

running ci for commits like [tx] updated from transifex will not restrict the merge but still, we can know about the failure on the ci run for that same commit. maybe we should start running acceptance tests for such commits too?

[kiranparajuli589]

Fixed by new transifex commit?

still the same case #39933 (comment) :(

[phil-davis]

See my comment #39934 (comment)

It needs to be sorted out on Transifex.

[kiranparajuli589]

Related tests are now skipped for oCV10 in #39934

[kulmann]

fr_FR just recently appeared in transifex and has far less translation percentage than fr, see screenshot:

We could define a minimum percentage for languages to be fetched from transifex at all. Config happens in https://github.com/owncloud/core/blob/master/l10n/.tx/config
That would also mean that translations are not available for certain apps anymore that have a good translation coverage. So probably not a good option. Deleting the language in transifex would have an even worse effect and (as @DeepDiver1975 pointed out in chat) would probably be recreated by transifex automatically.

[DeepDiver1975]

Following options do exist:

• explicit remove fr_FR after pulling from transifex
• got with a minimum-perc of 50% - this will filter out quite a lot of half-hearted translations (but also some languages will miss parts - e.g. fedsharing, files-external and files-sharing on Ukrainian)
• compile (and maintain) a list of languages we want to pull it - full control - but effort

[kulmann]

• compile (and maintain) a list of languages we want to pull it - full control - but effort

For reference, this option is what was done in oC Web, see https://github.com/owncloud/web/blob/320e06920cbee501f868a91dcff28b67abf72cd5/packages/web-runtime/l10n/Makefile#L23

[DeepDiver1975]

• compile (and maintain) a list of languages we want to pull it - full control - but effort

For reference, this option is what was done in oC Web, see https://github.com/owncloud/web/blob/320e06920cbee501f868a91dcff28b67abf72cd5/packages/web-runtime/l10n/Makefile#L23

yep - we learned from past misstakes when moving on .... ;-)

[phil-davis]

I will make a PR to cleanup the fr_FR files. See #39939

[jnweiger]

Confirmed fixed in 10.10.0 RC1

/lib/l10n/fr_FR* not present.