phasing out desktop-file-translations
Hi. I am working on a project of phasing out of desktop-file-translations: https://en.opensuse.org/openSUSE:Update-desktop-files_deprecation This project was started in 2003 to fulfill a goal of 100% translation of the desktop menu. Initially, Novell paid a substantial amount of money to complete this translation to supported languages. Later, the project was driven by the community. Increasing number of packages in the distribution made the project larger and larger. The project was extended to translate all desktop files in the product. Not only the desktop menu. So now we have a set of custom translations for all screensaver hacks, Amarok modules, stencils and templates for Calligra, names of KDE 4 and KDE 5 services, layout names for Umbrello 5 and much more. The implementation ignores the fact that many of included projects have their own translation projects, and duplicates the translation work. Or even worse, it forces the > 20 years old SUSE customizations over the recent upstream development. Nobody realized how big the project is in recent days. Now it includes about 20000 strings to translate. And translators have already translated about 380000 strings, which corresponds to about 20 human years of work. An unfortunate implementation following the "downstream only" way causes that we were not able to upstream these translations, return to the upstream nor drop this project any time later, as it would cause an unknown level of translation regression. In the later years, the "downstream only" was changed to "downstream first", but still, there was no way to return translations back to the upstream to save maintenance, translators' work, and as it is required by the recent "upstream first" policy. This starts to change in Factory. I made an improvement that changes the way it works, and suggests to upstream changes that it does. It would be a huge amount of work. Thousands of packages, thousands of upstreams. But as a result, we can start to use pure upstream packages, not only using the upstream code but also the upstream translations. There are first steps that will be done: 1. Projects are going to be locked in Weblate, and possibly also in GitHub. 2. Last translation updates will be sent to Factory. 3. New products will not get any new branch of update-desktop-files, and the desktop collection scripts will be never more called. Notes: - subprojects that are not phased out: - update-desktop-files-yast: We are the upstream here. And as YaST is slowly dying now, it does not make sense to spend a time on a more straightforward translation tool. - update-desktop-files-directories: Strings from the former Novell Linux Desktop 9 menu structure. Questionable. Is there any reasonable upstream for that? There is another large volume project: packages-i18n. It contains translations for all RPM packages in our products. There are more than 80000 strings to translate and I cannot imagine that it would be even 10% finished at any time in the future. Anyway, translators already spent more than 10 human years there. It makes sense to deprecate it as well, or at least use automated translation for it. Best regards -- Stanislav Brabec
Hello Stanislav Updating desktop-file-translations was quite painful recently, so this is highly welcome! Thank you very much for your effort! On Mon, Nov 4, 2024 at 11:59 PM Stanislav Brabec <sbrabec@suse.com> wrote:
Hi.
I am working on a project of phasing out of desktop-file-translations: https://en.opensuse.org/openSUSE:Update-desktop-files_deprecation
This project was started in 2003 to fulfill a goal of 100% translation of the desktop menu.
Initially, Novell paid a substantial amount of money to complete this translation to supported languages. Later, the project was driven by the community. Increasing number of packages in the distribution made the project larger and larger. The project was extended to translate all desktop files in the product. Not only the desktop menu. So now we have a set of custom translations for all screensaver hacks, Amarok modules, stencils and templates for Calligra, names of KDE 4 and KDE 5 services, layout names for Umbrello 5 and much more. The implementation ignores the fact that many of included projects have their own translation projects, and duplicates the translation work. Or even worse, it forces the > 20 years old SUSE customizations over the recent upstream development.
Nobody realized how big the project is in recent days. Now it includes about 20000 strings to translate. And translators have already translated about 380000 strings, which corresponds to about 20 human years of work.
An unfortunate implementation following the "downstream only" way causes that we were not able to upstream these translations, return to the upstream nor drop this project any time later, as it would cause an unknown level of translation regression.
In the later years, the "downstream only" was changed to "downstream first", but still, there was no way to return translations back to the upstream to save maintenance, translators' work, and as it is required by the recent "upstream first" policy.
This starts to change in Factory. I made an improvement that changes the way it works, and suggests to upstream changes that it does. It would be a huge amount of work. Thousands of packages, thousands of upstreams. But as a result, we can start to use pure upstream packages, not only using the upstream code but also the upstream translations.
There are first steps that will be done: 1. Projects are going to be locked in Weblate, and possibly also in GitHub. 2. Last translation updates will be sent to Factory. 3. New products will not get any new branch of update-desktop-files, and the desktop collection scripts will be never more called.
Notes: - subprojects that are not phased out: - update-desktop-files-yast: We are the upstream here. And as YaST is slowly dying now, it does not make sense to spend a time on a more straightforward translation tool. - update-desktop-files-directories: Strings from the former Novell Linux Desktop 9 menu structure. Questionable. Is there any reasonable upstream for that?
There is another large volume project: packages-i18n. It contains translations for all RPM packages in our products. There are more than 80000 strings to translate and I cannot imagine that it would be even 10% finished at any time in the future. Anyway, translators already spent more than 10 human years there. It makes sense to deprecate it as well, or at least use automated translation for it.
Best regards -- Stanislav Brabec
-- Best regards Luboš Kocman openSUSE Leap Release Manager
participants (2)
-
Lubos Kocman -
Stanislav Brabec