Skip to content

refactor(softwarecatalog): translate 12 pre-existing Dutch property names - #513

Merged
rubenvdlinde merged 1 commit into
developmentfrom
tr2/english-vocabulary
Aug 14, 2026
Merged

refactor(softwarecatalog): translate 12 pre-existing Dutch property names#513
rubenvdlinde merged 1 commit into
developmentfrom
tr2/english-vocabulary

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Tranche 2 of the Dutch→English vocabulary programme.

Measured at 28 Dutch property names against real wordlists (274,937 English,
164,174 Dutch; a token is Dutch when the Dutch list has it and the English list
does not). 12 move here. 13 are held back, and that half is the more useful
one — each needs a decision rather than a rename:

held back why
organisatie, contactpersoon, dienst, gebruik, moduleVersie, bioMaatregel Each is also a schema slug. A quoted 'organisatie' in PHP is a schema reference in one place and a property key in another — 107 of them — and nothing in the token tells them apart. Needs the schema rename decided with it.
domein One of the four facet dimensions the endpoint declares as query parameters and response keys. Renaming one of four is what broke filtering in tranche 1; they move together, as their own change.
bron The Relation schema declares both bron and source for one concept. A rename would silently merge two columns. The duplication is the defect.
omschrijving The COLUMN_MAP is flat and already maps omschrijvingdescription. The remaining occurrence is in a schema that already declares description, so it would need summary — one source cannot have two targets.
alg, bomRef, tooi, *Url JOSE header, CycloneDX field, TOOI register, url. Not Dutch.

Three defects in my own tooling, found by tests rather than review

  1. The unquoted-object-key pattern never fired. Its (?!:) guard — meant to
    skip PHP :: — sat immediately after the name, where the next character is
    the colon being matched, so it could never pass. Every beschrijvingKort:
    payload key was left behind while its value was renamed, so the suite wizard
    POSTed a key the schema no longer declares.
  2. Running the applier twice rewrote the migration map's own left-hand side.
    The map is a .php file under lib/, so 'afkorting' => 'abbreviation'
    became 'abbreviation' => 'abbreviation' — a no-op that also destroys the
    only record of the column's old name, and it took a pre-existing entry with
    it. The map and its test are excluded from the rename now.
  3. A destructured parameter is shorthand too.
    buildOrganisationCoverage({ gebruiken }) kept its parameter while one call
    site moved to usages:; the function read an undefined key and returned an
    empty coverage array.

This app's own suite caught two of them, including a positive control asserting
the register still declares Dutch columns. That control's threshold (> 20) was
a snapshot of how much Dutch remained, not a property of the guard — it is > 0
now, which is what it was for, with a note that the day it fails is the day the
test has nothing left to guard.

Verified against a control run of the same tree

check this branch control
PHPUnit 684, 1 error, 0 failures 684, 1 error
phpstan [OK] [OK]
psalm No errors found! No errors found!
jest / vitest 120/120 · 226/226
eslint / prettier / build 0 / clean / OK
routes resolved / broken 129 / 0
surviving uses in src/ 0

The 1 PHPUnit error is pre-existing on both sides — a missing
Symfony\Component\HttpFoundation\HeaderUtils in the standalone bootstrap.

10 migration entries appended; the map is verified free of duplicate and identity
entries.

…ames

Tranche 2. Measured at 28 Dutch property names against real wordlists; 12 move
here and 13 are held back with a reason each, which is the more useful half of
this commit.

HELD BACK, and why — these need a decision, not a rename:

  organisatie, contactpersoon, dienst, gebruik, moduleVersie, bioMaatregel
      Each is ALSO a schema slug. A quoted 'organisatie' in PHP is a schema
      reference in one place and a property key in another, and there are 107 of
      them; nothing in the token tells the two apart. The property rename needs
      the SCHEMA rename decided with it.

  domein
      One of the FOUR facet dimensions the endpoint declares as its query
      parameters and response keys. Renaming one of four is exactly what broke
      filtering in tranche 1 — they move together, as their own change.

  bron
      The `Relation` schema declares BOTH `bron` and `source`, two properties for
      one concept. A rename would silently merge two columns. The duplication is
      the defect and needs deciding.

  omschrijving
      The COLUMN_MAP is FLAT and already maps `omschrijving` -> `description`.
      The remaining occurrence sits in a schema that already declares
      `description`, so it would need `summary` — and one source cannot have two
      targets in a flat map.

  alg, bomRef, tooi, *Url
      JOSE header, CycloneDX field, TOOI register, and `url`. Not Dutch.

THREE DEFECTS IN MY OWN TOOLING, all found by tests rather than by review:

  1. The unquoted-object-key pattern NEVER FIRED. Its `(?!:)` guard — meant to
     skip PHP `::` — sat immediately after the name, where the next character is
     the very colon being matched, so it could never pass. Every `beschrijvingKort:`
     payload key was left behind while its VALUE was renamed, so the wizard POSTed
     a key the schema no longer declares. Moved inside the lookahead.
  2. Running the applier twice REWROTE THE MIGRATION MAP'S OWN LEFT-HAND SIDE.
     The map is a .php file under lib/, so `'afkorting' => 'abbreviation'` became
     `'abbreviation' => 'abbreviation'` — a no-op that also destroys the only
     record of the column's old name. It took a pre-existing entry with it. The
     map and its test are excluded from the rename now.
  3. A DESTRUCTURED PARAMETER is shorthand and has no colon either, so
     `buildOrganisationCoverage({ gebruiken })` kept its parameter while one call
     site moved to `usages:` — the function then read an undefined key and
     returned an empty coverage array.

The app's own test suite caught two of these, including a positive control
asserting the register still declares Dutch columns. That control's threshold
(`> 20`) was a snapshot of how much Dutch remained, not a property of the guard;
it is `> 0` now, which is what it was actually for, with a note that the day it
fails is the day the test has nothing left to guard.

VERIFIED against a control run of the same tree: PHPUnit 684 tests, 1 error on
BOTH (a pre-existing missing Symfony class), 0 failures; phpstan [OK]; psalm "No
errors found!"; jest 120/120; vitest 226/226; eslint 0; prettier clean; build OK;
0 broken routes; 0 surviving uses in src/. 10 migration entries appended, map
verified free of duplicate and identity entries.
@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/softwarecatalog @ 355989b

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
check-manifest
check-vue-demi
test-l10n
format
composer ✅ 130/130
npm ✅ 704/704
app:check-code ⏭️
info.xml
REUSE
PHPUnit
Newman ⏭️
Playwright
Hydra gates

Quality workflow — 2026-08-14 18:06 UTC

Download the full PDF report from the workflow artifacts.

@rubenvdlinde
rubenvdlinde merged commit 386771d into development Aug 14, 2026
40 of 43 checks passed
@rubenvdlinde
rubenvdlinde deleted the tr2/english-vocabulary branch August 14, 2026 19:29
rubenvdlinde added a commit that referenced this pull request Aug 16, 2026
…e whole voorzieningen register (#529)

The E2E (Playwright) job on `development` has not run a single test since
2026-08-14 19:29Z. It fails in the seed step, before Playwright starts, on
softwarecatalog's own honest gate:

    softwarecatalog has no register/schema mapping for:
      ['organisatie_schema', 'contactpersoon_schema', 'module_schema', 'contract_schema']

That gate is correct and the register really is unusable. The chain, read
from the failing job's own Nextcloud log (run 31937311499):

1. `view` and `bioMeasure` declare `objectDescriptionField: "summary"` while
   neither schema has a `summary` property. OpenRegister's
   `SchemaMapper::validateConfigField()` throws for exactly this, and
   `ImportHandler` logs
   `Failed to import schema: The value for objectDescriptionField ('summary')
   does not exist as a property in the schema.`
2. Both schemas are therefore absent from the import's `schemasMap`, so the
   `voorzieningen` and `vng-gemma` registers are imported without them —
   OpenRegister logs 18 `not found in schemasMap` warnings.
3. `SettingsService::configureVoorzieningen()` iterates the register's
   schemas to build the app-config map. With the links gone it writes
   `register` and nothing else, leaving every `*_schema` key empty.
4. `tests/e2e/ci-seed.sh` refuses to run Playwright against that. Correctly —
   the alternative is ~20 spec failures blaming the fixtures.

Where the two values came from: commit 386771d (#513, "translate 12
pre-existing Dutch property names") renamed the `view` schema's `summary`
property KEY to `omschrijving` and left `objectDescriptionField` pointing at
the old key, and separately rewrote `bioMeasure`'s `objectDescriptionField`
VALUE from `omschrijving` to `summary` while its property key stayed
`omschrijving`. Two dangling references, opposite directions, one commit.

This points both at the property each schema actually declares. It does not
rename anything: a property rename here is a data migration and belongs with
the vocabulary programme, not with an E2E fix.

Evidence, same instrument both sides — OpenRegister's own three acceptance
forms applied to the shipped register file, 20 schemas / 38 configuration
fields measured:

  before: 2 failures (view.objectDescriptionField, bioMeasure.objectDescriptionField)
  after:  0 failures

The new test reproduces that measurement in PHPUnit and carries a positive
control asserting the check can fail, so a future rename cannot silently
detach the register again. Run in a php:8.3-cli container (the host is 8.2):

  before fix: Tests: 4, Assertions: 21, Failures: 1  (naming both schemas)
  after fix:  OK (4 tests, 21 assertions)
  phpcs --standard=phpcs.xml on the new file: exit 0, 1 file measured

The test also records the two `objectSummaryField` values that dangle today
(`element`, `relation`). OpenRegister does not validate that key, so they are
inert — asserted as a known set rather than zero, so adding a new one fails
while the existing debt stays visible.
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.

1 participant