(This is experimental, and our concrete need to automate this is not
super high, but I want to have a solution for this problem in general.)
There are various automated ways to notify people of changes to a
component, without them having to set up complicated filtering.
For example
1. using GitHub's codeowners feature, perhaps creating a GitHub team
per component
2. by requiring all changes to the component to go through a fork
3. Using [public-inbox](https://public-inbox.org/)'s "lei" tool,
which makes it easy to create a filter for all patches touching a given file
(consumable as pull-based mbox or RSS feed), see
https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started
Option 3 seems ideal because it allows anyone to subscribe/unsubscribe,
and it remains obvious where to send PRs to.
It would be fairly easy to write a client-side tool (fetch all commits
and/or PRs and look for interesting changes) but people are more likely
to use something that works OOTB with newsreaders / mail clients.
Expose atom feeds of PRs proposing translation additions/removals.
The one with removals is higher traffic because it can be triggered
when rewording a source string.
Feeds are already online. For example, use:
https://raw.githubusercontent.com/fish-shell/fish-shell/fish-shell-events/po/zh_CN-additions.atomhttps://raw.githubusercontent.com/fish-shell/fish-shell/fish-shell-events/po/zh_CN-removals.atom
Ref: https://github.com/fish-shell/fish-shell/pull/11833#discussion_r2394161766
Default features are not needed for message extraction, so there is no
need to spend any resources on them.
If a PO files contains a syntax error, extraction would fail if the
`localize-messages` feature is active. This is undesirable, because it
results in an unnecessary failure with worse error messages than if the
`msgmerge` invocation of the `update_translations.fish` script fails.
Closes#11849
This command is only used to determine availability of `msgfmt`. Without
these changes, the entire help output shows up if the code panics later
on, which adds useless bloat to the output, making it harder to analyze
what went wrong.
Closes#11848
Prior to this, when `msgfmt` failed, this would be detected indirectly
by the parser, which would then panic due to it input being empty.
Explicit checking allows us to properly display `msgfmt`'s error
message.
Closes#11847
I'm not sure if our peer projects do this or if it's useful to have
on top of github releases (especially as most releases are patch
releases mainly).
We could certainly use "sphinx-build -b text" in
build_tools/release-notes.sh to extract a nice plaintext changelog
and send that, but that doesn't support links. Not sure about HTML
email either.
Use msgids to mark sections. In the PO format, comments are associated
with specific messages, which does not match the semantics for section
markers.
Furthermore, comments are not preserved by `msgmerge`, which required
quite convoluted handling to copy them over from the template.
By using msgids to mark sections, this problem is avoided.
This convoluted handling was also used for header comments. Header
comments are now handled in a simpler way. There is a fixed prefix,
identifying these comments, as well as a list variable containing the
lines which should be put into the header. When a PO file is generated,
all existing lines starting with the prefix are deleted, the and the
current version of the lines is prepended to the file.
Closes#11845
These should not be comments on an actual message, since they apply
throughout the entire file, so the sensible location is as comments on
the empty msgid.
Closes#11843
Running "fish -d reader" inside SSH inside Windows terminal sometimes
results in hangs on startup (or whenever we run "scrollback-push"),
because not all of the Primary DA response is available for reading
at once:
reader: Incomplete escape sequence: \e\[?61\;4\;6\;7\;14\;21\;22\;23\;24\;28\;32
Work around this by increasing the read timeout while we're waiting
for query responses.
We should try to find a better (more comprehensive?) fix in future,
but for the patch release, this small change will do.
Fixes#11841
Integration_4.1.1 fails to generate release notes with
CHANGELOG.rst:9: WARNING: Bullet list ends without a blank
line; unexpected unindent. [docutils].
We don't care about any specific attributes but we do very much care
about the specific query and response format associated with VT100's
primary device attribute query. Use a proper noun to emphasize that
we want that one and no other.
Ref: https://github.com/fish-shell/fish-shell/pull/11833#discussion_r2385659040
Executable path is empty only in contrived circumstances.
The regex error happens only when the user explicitly turns off a
feature flag.
The orphaned process error seems very unlikely, not worth translating.
The overwhelming majority of localizable messages comes from
completions:
$ ls share/completions/ | wc -l
$ 1048
OTOH functions also contribute a small amount, mostly via their
descriptions (so usually just one per file).
$ ls share/functions/ | wc -l
$ 237
Most of these are private and almost never shown to the user, so it's
not worth bothering translators with them. So:
- Skip private (see the parent commit) and deprecated functions.
- Skip wrapper functions like grep (where the translation seems to
be provided by apropos), and even the English description is not
helpful.
- Assume that most real systems have "seq", "realpath" etc.,
so it's no use providing our own translations for our fallbacks.
- Mark fish's own functions as tier1, and some barely-used functiosn
and completions as tier3, so we can order them that way in
po/*.po. Most translators should only look at tier1 and tier2.
In future we could disable localization for tier3.
See the explanation at the bottom of
tests/checks/message-localization-tier-is-declared.fish
Part of #11833
WezTerm allows applications to enable modifyOtherKeys by default.
Its implementation has issues on non-English or non-QWERTY layouts,
see https://github.com/wezterm/wezterm/issues/6087 and #11204.
fish 4.0.1 disabled modifyOtherKeys on WezTerm specifically
(7ee6d91ba0 (Work around keyboard-layout related bugs in WezTerm's
modifyOtherKeys, 2025-03-03)), fish 4.1.0 didn't, because at that
time, WezTerm would advertise support for the kitty keyboard protocol
(even if applications are not allowed to enable it) which would make
fish skip requesting the legacy modifyOtherKeys.
WezTerm no longer advertises that if config.enable_kitty_keyboard
is false. Let's work around it in another way.
I only tested with embedded-builds; CMake tests were failing because
they use different code paths here.
fish_config could use some love. Start by extracting common
functionality between "{theme,prompt} show", fixing the behavior.
Fixes 29a35a7951 (fish_config: fix "prompt/theme show" in embed-data
builds, 2025-09-28).
Commit 2b74affaf0 (Add prompt selector, 2021-04-22)
intentionally added an unused code path that checks for
$__fish_data_dir/sample_prompts, see
https://github.com/fish-shell/fish-shell/pull/7958#discussion_r621320945
> (note: This was added in preparation of moving the sample_prompts directory out of web_config -
> because it no longer is web-exclusive)
Remove it.
