update es translation - #859

…ule-project#912)

Extends existing categories (preferring extensions over new lines):
- Performance/Upload: amule-project#898 SlotAllocation default raised.
- Networking & Discovery: wire-parser hardening list extended with
  amule-project#879/amule-project#882/amule-project#890/amule-project#886; new amuleweb security hardening bullet
  consolidating ngosang's amule-project#869-amule-project#874 triage (all landed in amule-project#875);
  amulegui list extended with amule-project#857; shared-folder watcher extended
  with amule-project#858.
- Packaging: Windows installer i18n line extended with amule-project#899.
- Internals & Refactoring: new docs-polish + code-quality bullets
  covering amule-project#851/amule-project#855/amule-project#862/amule-project#888/amule-project#900/amule-project#866/amule-project#867/amule-project#895 and amule-project#909/amule-project#910/amule-project#912.
- Translations: new pre-release final-wave bullet covering amule-project#847/amule-project#856/
  amule-project#891/amule-project#908/amule-project#860/amule-project#904/amule-project#859/amule-project#863/amule-project#861/amule-project#880/amule-project#911/amule-project#901/amule-project#902/amule-project#889/amule-project#868/amule-project#853.
- Bug Fixes & Stability: amule-project#850/amule-project#854/amule-project#878/amule-project#906.
- CI: ccache wiring (amule-project#892, amule-project#903) + CodeQL binutils-dev (amule-project#907).

Contributors footer gains mifritscher and nguyenhoangminhhieu2004-gif
(both first-time contributors).

PR index extended through amule-project#912.

Extends existing categories (preferring extensions over new lines):
- Performance/Upload: #898 SlotAllocation default raised.
- Networking & Discovery: wire-parser hardening list extended with
  #879/#882/#890/#886; new amuleweb security hardening bullet
  consolidating ngosang's #869-#874 triage (all landed in #875);
  amulegui list extended with #857; shared-folder watcher extended
  with #858.
- Packaging: Windows installer i18n line extended with #899.
- Internals & Refactoring: new docs-polish + code-quality bullets
  covering #851/#855/#862/#888/#900/#866/#867/#895 and #909/#910/#912.
- Translations: new pre-release final-wave bullet covering #847/#856/
  #891/#908/#860/#904/#859/#863/#861/#880/#911/#901/#902/#889/#868/#853.
- Bug Fixes & Stability: #850/#854/#878/#906.
- CI: ccache wiring (#892, #903) + CodeQL binutils-dev (#907).

Contributors footer gains mifritscher and nguyenhoangminhhieu2004-gif
(both first-time contributors).

PR index extended through #912.

…aemon (amule-project#859)

* fix(gui): keep the shared-folder editor's paths out of its list cells

PopulateSharedDirsList() wrote each root's GetPrintable() into the list and
HarvestSharedDirsList() rebuilt a CPath from that cell text, so the value
that reached the daemon was whatever survived a trip through CPath's display
form. That form is not the path: on macOS wxConvFileName normalises to NFD,
so a precomposed accented character comes back decomposed -- same
characters, different bytes. Measured on a path holding U+00F6:

  raw        2F 4D C3 B6 74
  printable  2F 4D 6F CC 88 74

HarvestSharedDirsList() runs on every OK whether or not the page was
touched, so opening Preferences and confirming was enough to rewrite an
accented shared root into a form a byte-exact filesystem does not have --
which is what a Linux daemon presents to a macOS amulegui, the ordinary
remote-GUI deployment. The daemon then reports the folder as not found.

Only macOS diverges: the same probe on Ubuntu ARM64 and Windows ARM64
returns printable == raw for every input tried, including deliberately
locale-invalid byte sequences, because neither applies NFD. The persistence
side was never affected -- CPath::ToUniv()/FromUniv() round-trips the
filesystem bytes exactly, which is why remote.conf held the right value
while the dialog handed back a different one.

So the list no longer carries paths at all. SetListRowPath() records the
CPath and tags the row with its index, GetListRowPath() reads it back, and
the cell text is display only. The duplicate check moves to comparing paths
rather than cell text, where the same divergence could let a duplicate
through.

Placed as file-local helpers next to the editor rather than on the class:
the path-mappings editor in the works needs exactly the same treatment and
lives in this file too.

* test(path): pin the univ round-trip the editors depend on

CPath::ToUniv()/FromUniv() is what carries a path through a config file or a
list control, and the property that makes it safe -- that it reproduces the
filesystem bytes -- had no test. GetPrintable() does not have that property:
on macOS wxConvFileName normalises to NFD, so the same characters come back
as different bytes and a CPath rebuilt from the display form is a different
path to a byte-exact filesystem.

Covers a precomposed accented character (what NFD decomposes), CJK (which
has no decomposition), and a byte sequence that is not valid UTF-8. Asserts
only the round trip, not the divergence: printable == raw on Linux and
Windows, which do not normalise, so asserting otherwise would pin
macOS-specific behaviour.

* fix(gui): stop the shared-folder editor sending the daemon a bad list

Two ways the remote editor could hand the daemon something wrong, both on
the commit path.

CommitSharedDirsWithProgress() harvested the editor and sent the result on
every OK, with no test for whether the user had changed anything. The
monolithic branch of the same function has always gated on
m_ShareSelector->HasChanged; the remote branch gated on nothing. That is
reachable, not merely wasteful: PopulateSharedDirsList() fills the editor
from glob_prefs, which is empty until the first GET_SHARED_DIRS reply
arrives -- LoadSharedDirsRemote() is fired right after the populate, and the
reply repaints the editor when it lands. Open Preferences promptly after
connecting and confirm before that happens, and the harvest reads an empty
editor and hands the daemon an EC_OP_SET_SHARED_DIRS with no directories at
all. SendSharedDirsToRemote() declines only for a daemon too old to support
the operation, so a capable one is told, accurately, to share nothing.

Gated on m_sharedDirsDirty, which Add and Remove already set and which
EndSharedDirsSession() clears. Returning NothingToCommit rather than
Committed is correct for the three callers that read the result: each only
decides whether a reload is still owed, and one is owed precisely when the
shares were not committed here.

Second, GetListRowPath() answers a row carrying no recorded path with
wxFAIL_MSG and an empty CPath. The assert is debug-only, so a release build
would put that empty path into explicitDirs and send it as an empty
EC_TAG_SHAREDDIR. Every row is created through SetListRowPath(), so this is
a can't-happen -- but one that degrades into corrupting the share list, and
one line makes it harmless.

* fix(gui): keep the shared-folder editor read-only until the daemon's list lands

Gating the commit on m_sharedDirsDirty closes the untouched-OK case but not
its edited sibling. TransferToWindow() populates the editor from glob_prefs
and only then asks the daemon for the real list, and
RefreshSharedDirsIfOpen() deliberately skips the repaint once the editor is
dirty, so that an in-progress edit is not overwritten. In the window before
the first reply those two combine badly: adding a folder marks the editor
dirty, the arriving reply is discarded to protect that edit, and OK commits
a list holding only the row just added -- the daemon's existing shares go.

It needs the add to complete inside one EC round trip, so typing a path
makes it unlikely in practice, but nothing rules it out.

So the edit controls now come up disabled and are enabled by the reply, the
same way they are already gated on the daemon supporting the operation at
all. An edit can no longer precede the data it would overwrite, and the
dirty-skip goes back to meaning what it says -- protecting an edit made
after one reply from a later one.

The flag resets at the top of TransferToWindow()'s remote branch rather than
at close, because the dialog is constructed once and reused for every open.

Also corrects the comment there, which claimed the reply repaint meant "an
edit is never made against a stale list". That was the intent, but the
dirty-skip is exactly what broke it.

…amule-project#854)

* feat(gui): amuleGUI remote-to-local path mappings (amule-project#843)

FileLaunch::Open()/Reveal() silently disable themselves whenever the
daemon-reported path doesn't exist verbatim on amuleGUI's own machine,
which is always true for a genuinely remote daemon unless the exact
same absolute path happens to be independently mounted. Lets the user
configure a table of remote->local path-prefix mappings (e.g. the
daemon's /downloads/incoming reachable here as
D:\Downloads\aMule\incoming via a Samba mount) so those actions work
against a remote daemon whose filesystem is otherwise reachable.

Storage is genuinely GUI-local: CPreferences::PathMapping /
Load|SavePathMappings() read and write wxConfigBase::Get() directly
(which already resolves to remote.conf under CLIENT_GUI), never
through LoadAllItems()/SaveAllItems()'s Cfg_Base walk and never added
to CPreferencesRem's m_exchange_send_selected_prefs /
m_exchange_recv_selected_prefs -- so this never round-trips over EC.
Two existing "list of items" precedents looked reusable but weren't:
Categories and the shared-dirs editor both look locally persisted but
are actually daemon-owned, silently overwritten by the next EC pull.
Took SaveCats()'s per-row wxConfigBase group shape without its
EC-backed data source.

Applied in FileLaunch::ResolvePath(), the single choke point every
Open/Reveal/availability check already goes through (six call sites
across DownloadListCtrl.cpp and SharedFilesCtrl.cpp, none touched).
ApplyPathMapping() does plain string-prefix substitution on the raw
daemon path before it becomes a CPath -- CPath has no notion of a
second machine's separator convention, so the remote side is compared
and rewritten as a string, never parsed as this host's path syntax.
First matching prefix in the user's list order wins (no implicit
longest-prefix-match).

New "Path Mappings" Preferences page, CLIENT_GUI-only, modelled on the
existing shared-dirs list editor's widget shape (wxListCtrl + text
entry + Add/Remove) but without its EC round-trip/dirty-flag/session
machinery, which exists only to survive a background daemon refresh
that cannot happen to a purely local list.

Known gap: developed and tested on macOS. The substitution itself is
separator-agnostic pure string logic, and mingw-w64 CI confirms the
Windows build compiles, but an actual Samba-mounted drive-letter/UNC
mapping has not been exercised end-to-end this round.

Verified: amule (CLIENT_GUI off) and amulegui (CLIENT_GUI on) build
clean from a fresh CMake configure; pinned clang-format v18 clean;
Tier-1 clang-tidy clean via the local CI replica against upstream/master
(caught and fixed one real hit: an unconditional CPath copy in
ResolvePath() that's wasted work on the non-CLIENT_GUI build, where
the mapping branch never runs).

* fix(gui): address review findings on amule-project#843 path mappings, rebase onto master

got3nks's review on amule-project#854 (github.com/amule-org/pull/854):

1. A trailing separator on the remote prefix silently corrupted every
   path it mapped: the substitution is localPrefix + remainder, and
   CPath's constructor does not strip trailing separators, so remote
   "/downloads/" + local "/Volumes/dl" produced
   "/Volumes/dlincoming/f.avi" instead of "/Volumes/dl/incoming/f.avi".
   Browse never supplies a trailing separator (wxDirDialog::GetPath()
   doesn't return one) but a user describing a remote *directory*
   naturally types one, so this was the likely path through the UI, not
   a corner case. Fixed by stripping trailing separators from both
   prefixes wherever they're accepted: OnPathMappingAdd() (entry) and
   LoadPathMappings() (an existing config saved before this fix, or
   hand-edited).
2. ApplyPathMapping()'s prefix match had no boundary check: a mapping for
   "/mnt/data" also matched "/mnt/data-old/f.avi". Fixed by requiring the
   character after the prefix to be a separator (either convention, since
   the daemon's OS isn't known here) or the whole string to match.
3. The explanatory paragraph above the mapping list didn't use the panel
   width: muuli_wdr.cpp's one-shot Wrap(380) baked fixed line breaks at
   construction while the sizer's Expand() only stretched the control,
   leaving an empty right margin, and never re-flowed on resize (the
   dialog has wxRESIZE_BORDER) or DPI. Fixed by dropping the Wrap() from
   muuli_wdr.cpp (layout construction only, per that file's convention)
   and re-wrapping from the control's own real, DPI-scaled client width
   in PrefsUnifiedDlg -- once in PopulatePathMappingList() and again on
   every resize via a runtime Bind(wxEVT_SIZE) (size events don't
   propagate through the static event table the way command events do,
   so this can't be a wxDECLARE_EVENT_TABLE() row).
   Minor: OnPathMappingAdd() also now tells the user why nothing happened
   on empty/duplicate input instead of silently no-opping.

Also rebased onto current master to pick up amule-project#859, which fixed the same
"cell text is not a round-trippable CPath" bug (macOS NFD-normalisation
mismatch) in the shared-dirs editor this one was modelled on, and
extracted SetListRowPath()/GetListRowPath() for exactly this reuse.
Path-mapping's local-prefix column now goes through them instead of
GetPrintable()/CPath(text) round-tripping by hand.

Verified: rebuilt amule, amuled and amulegui locally, all clean.
po/ regenerated -- msgid delta +13/-0 (11 carried over from the original
amule-project#843 strings the rebase's po/ conflict resolution reset to upstream, plus
2 new validation-message strings from this fix).

* fix(gui): re-flow the path-mapping hint from the page, not from itself

The re-wrap added for the review's layout point read the paragraph's own
width and rewrote the paragraph from inside that paragraph's size handler.
wxStaticText::SetLabel() resizes the control to fit its new label, so the
handler fed itself: restoring the unwrapped text to re-flow made the control
briefly as wide as the whole sentence, that width came back as another size
event, and the two alternated until the stack was gone (EXC_BAD_ACCESS,
"excessive recursion", inside SetLabel under NSView setFrameSize).

Bound on the page instead. A page's width is set by the dialog and is
unmoved by anything its children do, so the input to the wrap no longer
depends on what the wrap changes and the loop is gone structurally rather
than by hoping the widths converge. Re-wrapping is additionally skipped when
the width has not moved, so a height-only relayout costs nothing, and
page->Layout() runs afterwards so the list follows the paragraph's new
height.

Two things the earlier version could not do, now fixed with it:

Wrap() only ever inserts breaks -- it re-reads the current label and treats
newlines already in it as hard -- so wrapping in place could narrow the text
but never rejoin it. Widening the dialog left the paragraph at its old
narrow width, which is the empty right margin the review was about, just
reached by resizing instead of baked in. The unwrapped text is kept and
restored before each wrap.

muuli_wdr.cpp wraps once again at construction, which the fix had dropped.
An unwrapped wxStaticText reports its whole single line as its best width
and the sizer turns that into the page's minimum, so the dialog opened as
wide as the sentence. It is bounded there and re-flowed from here; the bound
is parent->FromDIP(380) rather than a raw pixel count, which was the part
that read cramped on a HiDPI display.

Also adds the include for StripSeparators, which Preferences.cpp had been
getting transitively.

Tested on macOS: the page opens at a sane width, the paragraph fills it, and
it re-flows both wider and narrower under a continuous drag.

* fix(gui): make path mapping work in both directions across OS conventions

Two gaps the trailing-separator trim left, both about the mapping's two
halves coming from machines that need not agree on a separator.

The trim used StripSeparators(), which consults *this* host's separator set.
On a POSIX build that set has no backslash, so a Windows daemon's "D:\dl\"
kept its trailing separator and the join ran the halves together -- exactly
the corruption the trim exists to prevent, alive in the mirror direction (a
Linux or macOS amulegui against a Windows daemon). The remote prefix is now
trimmed by CPreferences::TrimRemotePrefix(), which accepts either convention
because the daemon's OS is not knowable here -- the same reason the prefix
boundary test already accepts either character.

And the remainder spliced onto the local prefix keeps the daemon's
separators, so a POSIX daemon feeds '/' into a path about to be handed to
Win32. Most of Win32 takes that, but "explorer /select," -- which is what
Reveal() runs, and the reason this feature exists -- is the fussy one.
Normalised on Windows only: '/' cannot occur in a Windows filename, whereas
a backslash is an ordinary character in a POSIX one, so the mirror rewrite
would corrupt names instead of fixing separators.

Verified on Windows that Win32 resolves mixed separators (Test-Path on
"C:\dir/sub/f.txt" is true), so availability and Open were already fine
there; this is for Reveal and for the POSIX-client-Windows-daemon direction.

---------

Co-authored-by: got3nks <[email protected]>