action #100023
closedrun desktop-file translation extractor
Description
the extractor of desktop file translations that pushed to github needs to be enabled
on https://github.com/openSUSE/desktop-file-translations
Run
cd 51-xml
./download_data.sh download
./generate_and_merge_pos.sh download
git add */*.po */*.pot
git commit -m update
git push
Updated by lkocman about 2 years ago
- Status changed from New to Blocked
- Assignee set to lkocman
blocked on access https://progress.opensuse.org/issues/107641
Updated by favogt about 2 years ago
- Assignee deleted (
lkocman)
It's unfortunately a more involved than that. The script still expects that all packages are built within openSUSE:Leap:15.x, but after CtLG that's no longer true.
Copying tarballs from backports would be simple to add, but unfortunately the biggest issue is SLE. There's no rsync access to IBS (that I know of) and the OBS mirror does not contain the tarballs.
So either we'll have to get the SLE files somehow or drop the mechanism altogether. Unfortunately at least YaST relies on the mechanism, as the .desktop files it ships do not contain translations on their own.
Updated by sbrabec about 2 years ago
I just ran the scripts and updated:
https://github.com/openSUSE/desktop-file-translations/commit/8abf067773cd45ec163cb3022ab331e41f9a0727
https://github.com/openSUSE/desktop-file-translations/commit/05f03b45827723f6346fb65f35273881ad073d81
Please let me know whether I should revert. I think that it is not a big issue, as we really want to translate yast and directories.
That the rest should not even exist, as it just duplicates the upstream translation. It made sense 15 years ago, when the upstream ignored I18N, and we wanted to be able to make post-release translation updated.
I think that we should start to deprecate the rest, check the upstream translation, send the unique translations to the upstream and drop the rest that already has upstream translations.
The way we are translating desktop files is pretty confusing and SUSE specific. For example see https://bugzilla.opensuse.org/show_bug.cgi?id=1118859
There is more in the documentation I am working on (internal only):
https://confluence.suse.com/display/packaging/Preparing+translations+for+new+SUSE+product
Updated by lkocman about 2 years ago
Thank you very much Stanislav
Is there any next step than needs to happen, to get these in place?
E.g. https://build.opensuse.org/package/show/openSUSE:Leap:15.4/update-desktop-files not sure if this doesn't have to be rebuild for SLE 15 SP4 (it's comming from SLE-15:GA/Update)
Thank you
Updated by sbrabec about 2 years ago
Next step: Wait for translations and submit (to SLE, the package is common). As I see not new strings after this run, there is no need to wait for translations.
packages-i18n is another story. It has many new strings in patterns (the only domain that makes real sense to translate).
Updated by favogt about 2 years ago
sbrabec wrote:
I just ran the scripts and updated:
https://github.com/openSUSE/desktop-file-translations/commit/8abf067773cd45ec163cb3022ab331e41f9a0727
https://github.com/openSUSE/desktop-file-translations/commit/05f03b45827723f6346fb65f35273881ad073d81
How did you pull the source strings from SLE and Backports? I don't see any change adding that.
Updated by favogt about 2 years ago
- Status changed from In Progress to Blocked
favogt wrote:
sbrabec wrote:
I just ran the scripts and updated:
https://github.com/openSUSE/desktop-file-translations/commit/8abf067773cd45ec163cb3022ab331e41f9a0727
https://github.com/openSUSE/desktop-file-translations/commit/05f03b45827723f6346fb65f35273881ad073d81How did you pull the source strings from SLE and Backports? I don't see any change adding that.
As expected, it's missing most content since the 15.3 update:
commit 7db31a526f991956a8681910fbd7e067cff44ed4
Author: Stanislav Brabec <sbrabec@suse.cz>
Date: Tue Feb 2 23:32:02 2021 +0100
Update strings from Leap 15.2.
50-pot/appstreamdata.pot | 7654 +------------------------------------------------------
50-pot/polkitaction.pot | 4012 +----------------------------
50-pot/update-desktop-files-apps.pot | 27101 ++++++---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
50-pot/update-desktop-files.pot | 1991 +--------------
4 files changed, 801 insertions(+), 39957 deletions(-)
Updated by favogt about 2 years ago
Please let me know whether I should revert. I think that it is not a big issue, as we really want to translate yast and directories.
The issue is YaST and directories are from SLE and currently not updated.
The reason why this wasn't noticed yet is that the script does not delete the old .pot files before copying over the new ones, and so yast.pot isn't touched at all.
Updated by sbrabec about 2 years ago
favogt wrote:
Please let me know whether I should revert. I think that it is not a big issue, as we really want to translate yast and directories.
The issue is YaST and directories are from SLE and currently not updated.
The reason why this wasn't noticed yet is that the script does not delete the old .pot files before copying over the new ones, and so yast.pot isn't touched at all.
OK. Thanks. If you have some ideas to improve it, feel free to do it. I am trying to maintain it just because nobody else wants.
It would be nice to slowly migrate to a standard way translations are done: As part of the source code projects. These complicated string collectors and distributors are prone to errors.
Updated by favogt about 2 years ago
sbrabec wrote:
favogt wrote:
Please let me know whether I should revert. I think that it is not a big issue, as we really want to translate yast and directories.
The issue is YaST and directories are from SLE and currently not updated.
The reason why this wasn't noticed yet is that the script does not delete the old .pot files before copying over the new ones, and so yast.pot isn't touched at all.
OK. Thanks. If you have some ideas to improve it, feel free to do it.
Unfortunately I don't have a better idea than doing the downloads through the IBS API one package at a time. rsync would make that quicker, but that wouldn't solve the issue with SP layering and maintenance updates having separate binaries which need to be handled as well.
I am trying to maintain it just because nobody else wants.
Same...
I really wonder why this is done by the openSUSE side though and not the SLE side. It seems like this is necessary for SLE as well and should be dealt with there.
It would be nice to slowly migrate to a standard way translations are done: As part of the source code projects. These complicated string collectors and distributors are prone to errors.
Fully agreed. It might work to go the way of downloading only YaST and other relevant desktop files through the API. However, as the result has to be submitted to SLE, which is in a late stage of development, it might be too late to submit this anyway and it won't matter until SP5...
Updated by sbrabec about 2 years ago
favogt wrote:
I really wonder why this is done by the openSUSE side though and not the SLE side. It seems like this is necessary for SLE as well and should be dealt with there.
In past, there were two branches, two translation projects. And even two independent translations. When we started to use Weblate, both were merged. And now, when Leap and SLE uses the same binaries, I used openSUSE data to extract.
openSUSE has more packages. And SLE translation budget covers only yast and directories, which are hopefully equal for both. Or at least I hope so.
It would be nice to slowly migrate to a standard way translations are done: As part of the source code projects. These complicated string collectors and distributors are prone to errors.
Fully agreed. It might work to go the way of downloading only YaST and other relevant desktop files through the API. However, as the result has to be submitted to SLE, which is in a late stage of development, it might be too late to submit this anyway and it won't matter until SP5...
Well, if the translation will migrate to particular Git repositories, no API will be needed. make po-update or so will update po files, and Weblate will automatically fetch it. Translations could be ready even before the version release.
Yes, with that approach, packages has to be translated before new version is released. But it is a way most normal projects work: soft freeze, string freeze, hard freeze, release.
But it needs to move responsibility for the translation to the package maintainers instead of openSUSE Weblate server maintainer. Now the Weblate maintainer has to manually check that new translations were submitted to OBS.
Updated by lkocman almost 2 years ago
Team let me share this with particular ALP group. I feel we won't get this done for 15.4 and I suppose SLES 15 SPX might be hesitant to change workflow at this point in time (I'll cc Rado RM for 15 SP5).
Updated by lkocman almost 2 years ago
Team let me share this with particular ALP group. I feel we won't get this done for 15.4 and I suppose SLES 15 SPX might be hesitant to change workflow at this point in time (I'll cc Rado RM for 15 SP5).
Updated by lkocman almost 2 years ago
- Due date set to 2022-05-27
Emailed Padraig and Julia as per recommendation of Frank. Fabian and Stanislav are in cc. I'll keep the ticket in blocked state to keep track of the issue, but otherwise please consider it rejected post May 27th (GM build ETA)