Skip to content

update es translations: cpp + docs, manpages rebuilt - #655

Merged
mrjimenez merged 1 commit into
amule-project:masterfrom
danim7:translate-es
May 18, 2026
Merged

update es translations: cpp + docs, manpages rebuilt#655
mrjimenez merged 1 commit into
amule-project:masterfrom
danim7:translate-es

Conversation

@danim7

@danim7 danim7 commented May 18, 2026

Copy link
Copy Markdown
Contributor

Just updated the es translations: es.po + manpages-es.po
Also rebuild the manpages, since they are included in the repository.

@mrjimenez
mrjimenez merged commit f822a2c into amule-project:master May 18, 2026
12 checks passed
@danim7
danim7 deleted the translate-es branch June 9, 2026 16:34
mrjimenez pushed a commit to mrjimenez/amule that referenced this pull request Jul 30, 2026
…able, Web UI label CI gate (amule-project#655) (amule-project#696)

* refactor(amuleapi): make /preferences field names self-explanatory (amule-project#655)

Rename 45 of the 119 fields GET/PATCH /api/v0/preferences exposes so each
one states what it does without a lookup table, and nest the two unrelated
remote-control subsystems instead of prefixing every field. amuleapi has
not shipped and the protocol stays at v0, so the old names are simply
removed rather than dual-emitted.

The EC protocol is untouched: every tag number, presence-vs-value encoding
and thePrefs:: accessor stays as-is, so amulegui / amulecmd / amuleweb
remain compatible. All translation happens at the webapi boundary, the
same way extended_udp_port_enabled already inverts EC_TAG_CONN_UDP_DISABLE.

Highlights, by the class of problem each fixes:

- Misleading names: security.obfuscation_supported -> obfuscation_enabled
  (it is a writable preference, while _supported / _available elsewhere
  means a read-only build capability); message_filter.friends / .secure /
  .all -> accept_from_friends_only / accept_from_known_clients_only /
  filter_all_messages; directories.exclude_regex ->
  exclude_patterns_use_regex (a modifier on exclude_patterns, not a second
  list); files.preview_prio -> prioritize_first_last_chunks.
- Missing units: core_tweaks.srv_keepalive_timeout ->
  server_keepalive_timeout_ms (its two siblings already said _ms),
  connection.slot_allocation -> upload_slot_kbps, filebuffer ->
  file_buffer_bytes, online_signature.update_frequency ->
  update_frequency_seconds, webserver refresh -> refresh_seconds.
- Magic numbers: connection.proxy_type and security.can_see_shares (now
  shared_files_visibility) become enum strings. A new PrefTakeEnum helper
  maps them to the wire ints and also replaces the hand-rolled inline
  mapping ip2country.source was using.
- Structure: remote_controls.{webserver,amuleapi}.{...} replaces the nine
  webserver_* / amuleapi_* prefixes. Both sub-objects still pack into the
  single EC_TAG_PREFS_REMOTECTRL group, and passwords stay write-only.
- Abbreviations spelled out: dl / ul / prio / cat / srv / autoconn.

files.create_normal is deliberately left alone. It is the one field whose
positive name requires inverting its meaning, so it gets its own change.

The Web UI moves with the API in the same commit: field keys, the derived
prefs_field_* dictionary keys in both locales, and dotted category paths
for the nested objects. Two labels copied verbatim from the desktop are
reworded ("Slot Allocation" -> "Upload speed per slot (KB/s)"), and the
keepalive field now scales to minutes like the desktop slider instead of
showing a bare millisecond count.

check-i18n.mjs gains a check that every preferences field resolves to a
real label, and is wired into the i18n workflow. These label keys are
derived from the field names, so before this a renamed field with no
dictionary entry would have rendered the raw key with nothing failing.

Verified: full macOS build clean, 28/28 ctest green, curl phases 05 (73)
and 15 (117 incl. new nested remote_controls and enum coverage) pass
against a live daemon. Documented and emitted key sets diffed to zero.

* refactor(amuleapi): drive /preferences from one declarative field table (amule-project#655)

The 119 fields on /api/v0/preferences were described three times, in three
different idioms: a hand-written EC decode per category in Refresher, a
w.Key/w.Value pair per field in the GET emitter, and a PATCH applier that
had grown two parallel helper families -- 87 call sites on the generic
PrefTake* helpers plus 22 more on connection-local lambdas doing the same
job with their own error strings and a different return convention. A field
touched in two of the three and missed in the third compiled cleanly.

Replace all three with a walk over one table (PrefsSchema.{h,cpp}). Each row
names a field's JSON category and key, its EC tag, its type, how EC encodes
it, and whether it is readable, writable or neither. Adding a preference is
one row; renaming one is one token.

What used to be special-case code is now a column:

- `invert` -- extended_udp_port_enabled, whose EC tag (EC_TAG_CONN_UDP_DISABLE)
  is negatively named. This is also what makes the deferred create_normal ->
  create_sparse_files flip a one-value change instead of two structurally
  different edits on the read and write paths.
- `enc` -- presence-tag vs value-tag booleans, which the core serializer mixes
  (57 presence, 9 value) and which every reader previously had to know.
- `access` -- read-only capabilities and live status, write-only passwords and
  the ip2country trigger, and the amuleapi passwords that belong to
  /auth/passwords and are rejected here.
- `gated_by` -- the 409 when files.mmap_enabled is set against a core built
  without mmap.
- `read_group` -- connection.upnp_available, the one field whose EC tag lives
  in a different group ([General]) than its JSON category implies.

Rows carry the address of their backing member, and the PREF_* macros
static_assert that the declared PrefType matches the member's real C++ type,
so a mis-typed row fails the build rather than misbehaving at runtime.

One field genuinely cannot be described: remote_controls.webserver
.guest_enabled and .guest_password share a single EC tag, which carries the
enable bool as its value and the password hash as a child. There is no 1:1
field-to-tag mapping to write down, so its PATCH packing stays hand-written
and the schema marks it Bespoke. Its GET emission is still table-driven.

Equivalence was checked against a captured GET /preferences from the previous
build: the EC decode and the GET emitter each produce byte-identical output,
and the final key set matches at 119/119. PATCH is covered by curl phase 15
(117/117, unchanged) plus direct checks that every type, the inverted field,
the nested categories and each error path still behave. Error bodies are now
uniform ("<key> must be a bool") where they used to be per-category
("connection field must be a bool"); no test or doc asserted the old wording.

Two new tests pin the table's own invariants: no duplicate fields, every
category resolving to an EC group, members present exactly for the rows that
round-trip a value, enum rows carrying a name table, capability gates naming a
real sibling bool, and the emitted count staying at the documented 119. A
second test asserts the three irregularities above stay at one field each, so
a second one appearing is caught rather than copied.

Net: -1437 / +842 lines, with the prefs handling in Api.cpp down 912 lines and
Refresher.cpp down 212.

* feat(amuleapi)!: state the sparse-file preference positively (amule-project#655)

files.create_normal becomes files.create_sparse_files, and its meaning
inverts: create_sparse_files == !create_normal. This is the one field in the
payload whose positive name could not be reached by renaming alone, so the
issue asked for it on its own commit.

Every layer except EC already spoke in terms of "sparse". The config key is
/eMule/CreateSparseFiles, the core stores s_createFilesSparse (default on),
PartFile.cpp reads CreateFilesSparse(), and the desktop checkbox added in
amule-project#662 is labelled "Create new files as sparse files". Only the EC tag is named
for the negative case -- EC_TAG_FILES_CREATE_NORMAL is an empty tag present
only when sparse is off -- and amuleapi was the one consumer that took that
name and published it outward, leaving the Web UI saying "non-sparse" where
the desktop says "sparse" for the same setting.

EC is untouched: same tag number, same presence semantics, same
thePrefs::CreateFilesNormal(). The negation is undone at the webapi boundary
instead, exactly as extended_udp_port_enabled already does for
EC_TAG_CONN_UDP_DISABLE. Thanks to the schema table this is one column:

    PREF_BOOL("files", "create_sparse_files", EC_TAG_FILES_CREATE_NORMAL,
              PrefEnc::Presence, /*invert=*/true, ...)

The snapshot default flips to true to match the core's own default, and the
Web UI label moves to the desktop's positive wording, which also flips the
checkbox's rendered state for an unchanged setting.

Verified end to end against a daemon's own config file rather than just the
API's echo, since a polarity change is precisely where a self-consistent API
can still be wrong:

  CreateSparseFiles=1  -> GET create_sparse_files: true
  PATCH false          -> CreateSparseFiles=0 in amule.conf
  CreateSparseFiles=0  -> GET create_sparse_files: false
  PATCH true           -> CreateSparseFiles=1 in amule.conf

The schema-invariant test caught this change on its own: it enumerates which
fields may invert, so adding a second one failed until the list was updated
deliberately. That is the check working, and the list now names both tags and
why each is negative.

Note for clients: this is the one field where renaming the key without
flipping the value yields the opposite behaviour. Nothing ships with the old
name -- amuleapi is unreleased and the protocol stays at v0 -- so no
compatibility shim is carried.

* fix(amuleapi): keep the enum index unsigned in the prefs decoder

CECTag::GetInt() returns uint64_t, so copying it into an std::int64_t
narrows, which bugprone-narrowing-conversions flags on a new line. Keep the
index unsigned: the >= 0 half of the range check was dead weight anyway, and
the remaining bound is the only one that matters.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants