I plan to submit this. Feel free to provide feedback before I do it.
Title: Almost two years of YaST News
Subtitle: Recent changes and future plans at YaSTland
YaST, the flagship installer and configuration tool of openSUSE is in
constant development. Just as its unattended companion AutoYaST.
Although the YaST Team at SUSE tries to communicate progress as often as
possible in the YaST Blog, it has been almost two years since we
presented the "Top 25 New Features in (Auto)YaST" at openSUSE Conference
2020. So it's time for another live update!
We will recap the main changes and new features that are already
integrated into openSUSE Tumbleweed and that will be included at
openSUSE Leap 15.4, to be released just a couple of days after the talk.
We will also take a look to some ideas for future development... and we
really need the feedback of the whole openSUSE community for that. So
please join us and speak up!
Ancor González Sosa
YaST Team at SUSE Software Solutions
TL;DR: Use the "TRANSLATORS" tag for marking the comments for translators.
Currently we extract *all* preceding comments to the generated POT files. The side
effect is that in some cases the comment contains the license header, Yardoc comments
or even commented out code. That might be confusing for translators.
The solution is to use some special tag and instruct gettext to extract the
comments only following this special tag. We already use the "TRANSLATORS" tag
in YaST for that.
# this comment is *not* copied to the POT file
# TRANSLATORS: this comment *is* copied to the POT file
# this *is* copied as well
Unfortunately it is not used everywhere, when I tried to use it globally a lot of
comments from POT files were lost.
For that reason I have introduced the POTCOMMENTS file, similar to the existing
POTFILES used in some repositories. That file should contain the tag name passed to
gettext. I.e. it should just contain the "TRANSLATORS" value so it is the same in all
If that file is missing the old approach (all comments) is used, so it is backward
compatible and we can gradually fix the modules one by one.
See https://github.com/yast/yast-devtools/pull/166 for the implementation details
and https://github.com/yast/yast-firstboot/pull/136 as an example how it was fixed in
one YaST module.
SUSE LINUX, s.r.o.
18600 Praha 8
In SLES 15 SP3, how are the patterns and package descriptions translated?
Until SLES 12 SP5, we were modifying the package package-translations by merging the po files for a translated language and creating the package-translations-$lang.mo files
In SLES 15 SP3, I tried to do the same, merging all po files for a translated language and creating the package-translations-$lang.mo files.
Now in SLES 15 SP3 during installation, if I change the language I am not getting the translated description for the patterns.
I would really appreciate it if you could help us understand how to localize our patterns and package descriptions.
The SLE-15-SP4 branch has been created in all relevant YaST and libyui repositories.
- The "master" branch is now autosubmitted only to Factory.
- The SLE-15-SP4 branch is submitted to SLE-15-SP4 maintenance project,
if you still need to submit a fix to GA then you need to do that manually
("rake osc:commit" + "osc sr Devel:YaST:SLE-15-SP4 <package> SUSE:SLE-15-SP4:GA"
and reject that maintenance autosubmission).
- The already open SP4 pull requests need to change the target branch.
- The version in "master" was bumped to 4.5.0 (that might cause conflicts
in the already opened pull requests)
There are some additional improvements to the branching done in the past:
- The SP4 branch was merged to master and the specific SP4 changes (Rakefile, GitHub
Actions) were reverted. That means the first merge from SP4 to "master" will
be a clean merge, no need to revert that changes manually.
- The "openSUSE-15_4" branch has been created in the openSUSE Leap specific packages
which are not present in SLE (yast-alternatives, yast-docker, yast-migration-sle,
yast-slp-server). In the past the branching was missing for those... =:o
If you find any problem related to the branching then just ping me.
SUSE LINUX, s.r.o.
18600 Praha 8
After last Tuesday meeting, I have tried to build a short-term roadmap
for D-Installer. I put the first version of the roadmap in Confluence,
but as we want to keep it public, I decided to give GitHub projects
feature a try. You can find more information at GitHub documentation:
Regarding D-Installer, here is the result:
As you may see, I decided to just plan for three iterations and the
dates are probably not realistic at all. We will adjust them as we go
forward and gain more experience about the project.
Imobach González Sosa
YaST Team at SUSE LLC