November 2024 - openSUSE Translation - openSUSE Mailing Lists

Streamlining openSUSE Translations Upstream
by Vojtěch Zeisek 18 Nov '24

18 Nov '24

Hi, after reading <https://news.opensuse.org/2024/11/11/streamlining-translations> (BTW, it links discussion into forums.o.o, but it's locked;) I'm not sure, what everything does it mean in practice. AFAIK openSUSE does use e.g. <https://salsa.debian.org/manpages-l10n-team/manpages-l10n> which is fine, but I'm confused what everything will be affected. Only desktop files (see thread "phasing out desktop-file-translations"), or something else? Sincerely, V. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

2 2

[opensuse-translation] [Attention]YaST Software Management GTK broken because gtk.pot is broken!
by Marguerite Su 11 Nov '24

11 Nov '24

Hi, Karl and all other local translators: Please watch bug 801311: https://bugzilla.novell.com/show_bug.cgi?id=801311 (There's also a software bug in it and has been assigned, so I can't assign it to Karl at the same time) Our yast/50-pot/gtk.pot is now only 48 strings, comparing to 321 strings in qt-pkg.pot Some former commit before 12.3 destroyed all strings for the GTK interface. (ViewVC is currently broken, so I can't tell which commit) So we may have to re-do the work for a big update. Just reserve some time in your schedule, or your locale will be broken for the entire 12.3 life cycle! Greetings Marguerite -- To unsubscribe, e-mail: opensuse-translation+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-translation+owner(a)opensuse.org

4 5

phasing out desktop-file-translations
by Stanislav Brabec 05 Nov '24

05 Nov '24

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

2 1