Re: [PATCH] findmnt: (usage) add a needed equals sign before an optional argument

Karel Zak <[email protected]> Mon, 15 Sep 2025 11:22:18 +0200
Newsgroups org.kernel.vger.util-linux
Message-ID <cspldmiiosndipcki3zybaik2edrf2lstkpxxj27rum5xrlfdc@6a4t452pkz7l>
On Fri, Sep 12, 2025 at 04:47:57PM +0200, Benno Schulenberg wrote:
> 
> Op 12-09-2025 om 15:18 schreef Karel Zak:
> > On Thu, Sep 11, 2025 at 03:51:48PM +0200, Benno Schulenberg wrote:
> > > 
> > > Op 11-09-2025 om 15:48 schreef Benno Schulenberg:
> > > > -	fputs(_(" -k                     alias to '--kernel mountinfo'\n"), out);
> > > > -	fputs(_(" --kernel[=<method>]    search in kernel mount table (default)\n"
> > > > +	fputs(_(" -k                     an alias for '--kernel=mountinfo'\n"), out);
> > > > +	fputs(_(" --kernel[=<method>]    search in kernel mount table (default behavior);\n"
> > > 
> > > Karel, do you want to roll an rc2, or shall I just make these changes in
> > > rc1 POT file for the TP?
> > 
> > I think RC1 is sufficient for translations for stable releases; we
> > don’t need as long a stabilization period as for major releases.
> > That’s why I asked for an update on TP.
> > 
> > Or do you think including stable release updates on TP is overkill?
> 
> No -- offering stable dot releases for translation is fine,
> as long as the string changes are the same as made in master.

Changes in the stable branches will always be a subset of changes in
the master branch.

The stable branch is almost always about backports (see "cherry-picked
from" in the commit messages of 'git log stable/v2.41'), whereas in
the master branch we often make more invasive changes.

Also note that before a new master release I always sync po/ and
po-man/ against the latest translations from TP. This means the
initial versions of the po/ and po-man/ strings in the major release
2.42 will be from 2.41.2 (or so).

> What I'm asking is: will you apply the patch (both to master
> and to the stable branch)?  If yes, then I'll edit the rc1 POT
> file to correspond with those changes.  (I don't want to offer
> a faulty string and then see it corrected in the next POT.)

When translators are working on strings, it's best to keep them frozen
and do string fixes in the next release (or next -rc). So I have
applied the patch to the master branch only for now. OK?

For a major release (e.g., v2.42), it would be best to do string
translations twice before the final release to allow time to fix
strings and finalize the translations. Maybe for the final release
it would be best to have

-rc1 ... stabilization only, no translations
-rc2 ... translations, string fixes from translators
-rc3 ... final translations

But I'm not sure translators are ready for such repetitive work
(although the second update will probably be quite small).

    Karel

-- 
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com