Add Portuguese dictionary overrides for mistranslated names

[meketreve]

What this is

src/Perpetuum.ServerService2/data/customDictionary/ carries one overlay file per language, keyed by the language id in the comment block at the top of Perpetuum/CustomDictionary.cs. Session.SignIn picks the file matching the id the client asks for and merges it into the client's own dictionary.

There are files for English (0), Hungarian (1), German (2), French (5) and Polish (7). Portuguese (3) has none, so every string a Portuguese-speaking player reads comes straight from the machine-translated pass the client ships — and that pass is rough.

This PR adds 3.json with 153 corrections. It is an overlay in the same shape as the other five: names, labels and short UI strings only. Descriptions and body text are deliberately left alone.

The problems it fixes

Coined names were translated

The game's invented material and plant names had been run through a dictionary. The worst of it:

key	English	before	after
def_gravel	Solibdit	Solidão (loneliness)	Solibdit
def_gammaterial	Colixum	Colixo	Colixum
plant_grass_b	Fewulum	Poucolum ("few" translated)	Fewulum
def_stermonit	Stermonit	Estermonite	Stermonit
def_silgium	Silgium	Sílgio	Silgium
def_epriton	Epriton	Épriton	Epriton
def_electroplant_fruit	Noralgis	Norálgis	Noralgis
def_titan_rare_small	Titan-50 (PL-10)	Titã-50 (PL-10)	Titan-50 (PL-10)

The whole rare-material line had the same treatment: Stermid → Estermid, Colixid → Colixido, Helioquid → Helioquido, Prismocid → Prismocida, Tricarine → Tricarina.

German keeps every one of these names verbatim and Russian transliterates them intact — Коликсиум is Colixum, Солибдит is Solibdit. Portuguese was the only language inventing substitutes, which is the argument for this whole group.

Two extensions named the wrong material

key	English	before	after
ext_silgium_miner_expert	Extensive silgium exploitation	Exploração extensiva de silício (silicon)	Exploração extensiva de Silgium
ext_titan_miner_expert	Extensive titan mining	Extensa mineração de titãs (of giants)	Extensa mineração de Titan

def_titan (Titan ore) and def_titanium (Titanium) are separate materials in this game; the Portuguese pass had merged them, and def_ammo_mining_titan_patent even said "minério de titânio".

"Charge" was read as a billing charge

30 entries. cf_mining_ammo read "Cobranças de mineiro", cf_ammo_harvesting_patents read "Taxas de colheita" — invoices, not ammunition. A module's charge is a carga.

"Scan" was read as document digitisation

9 entries used digitalizar / digitalização, which is what you do to a paper document. Sweeping ground with the geoscanner is a varredura; scanning a unit, a container or an inventory is escanear.

One family, six wordings

The miner charge items carried six Portuguese wordings for two English ones — Carga do mineiro, Carga de mineiro, Carga de minerador, Carga de mineração profunda, Carga de minerador profundo, Carga de mineiro profundo. 43 entries now follow one pattern derived from the English shape: Carga de mineração (<material>) and Carga de mineração profunda (<material>), with Protótipo de and CT where the English has them.

Gender agreement

13 entries. Carga is feminine, so the geoscanner charges read "baseada em bloco", not "baseado".

How the corrections were produced

Every substitution is guarded by the English string: a rule only fires on a key whose English value contains the term being protected, so an unrelated Portuguese word that happens to look similar is never touched. The generated set was then read entry by entry, and six entries no rule could handle were written by hand: cf_harvesting_turret_units ("Colhendo torres", a gerund blunder), ext_syndicate_industry_specialist ("sindicalizado", unionised), and four category labels that had to be brought into step with the item names they head.

Verification

• json.loads with a duplicate-key hook: 153 entries, no duplicates, every value a string, UTF-8, no BOM, CRLF and 2-space indent matching 7.json.
• Placeholder integrity checked mechanically: every {%QUANTITY%} / {%DEFINITION%}, every [...] marker and every CT suffix present before is present after.
• No corrected value still contains any of the offending tokens.
• dotnet build PerpetuumServer2.sln -c Release -p:Platform=x64: 0 errors. The data/ folder is not referenced by any .csproj, so this file cannot affect the build; the run is only to show the tree is clean.

One thing worth a maintainer's eye

The running server currently has a 1.9 MB 3.json that is a full export of the client dictionary, not an overlay — it contains client UI strings like accept and avatar_beard. The same is true of the deployed 0.json, 2.json and 4.json. This PR adds an overlay in the shape of the tracked files. If the deployment copies this folder over the server's, the base Portuguese strings then have to come from the client, the way they already do for Hungarian, French and Polish. Worth confirming before it ships.

Russian (4) is in the same position as Portuguese was — deployed but untracked. Not touched here.

🤖 Generated with Claude Code

[meketreve]

Closing this. Per maintainer direction, a change belongs in one project only, and the dictionaries live in OPDB — Patches/Live_36/Server/data/customDictionary/3.json carries the full 18058 entry Portuguese export, added in 85ad932 (p36.7).

That also answers the question this PR's body asked. The base Portuguese strings come from the server's own export in OPDB, not from the client, so an overlay in this repo was the wrong shape: both repos own the same deployed path, and this repo's copy holds 153 entries against OPDB's 18058.

The corrections moved to OpenPerpetuum/OPDB#390, unchanged, as a partial staging file alongside the 0.json already staged there.