Jacek Pyziak
6ef8b0029d
Phase 2 complete: - Seed registration dictionary phrases - Update public and admin registration templates to use translations - Document PAUL plan, apply, summary, and changelog
9.9 KiB
9.9 KiB
phase, plan, type, wave, depends_on, files_modified, autonomous, delegation
| phase | plan | type | wave | depends_on | files_modified | autonomous | delegation | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 02-registration-dictionary-phrases | 01 | execute | 1 |
|
|
true | off |
Purpose
The client can manage conference wording from /_rejestracja/Admin/Dictionary/Index instead of requiring template edits for labels, option names, status values, and repeated summary text.
Output
- Dictionary seed SQL and an idempotent PHP runner for the new phrase set.
- Public registration form labels/options changed to
{translate word=...}/|translate. - Confirmation and admin registration views changed to use dictionary translations for repeated labels, option labels, yes/no/default values, and participation/diet display values.
Prior Work
@.paul/phases/01-registration-form-update/01-01-SUMMARY.md
Source Files
@_rejestracja/core/class/Dictionary.class.php @_rejestracja/core/plugins/Smarty/function.translate.php @_rejestracja/core/plugins/Smarty/modifier.translate.php @_rejestracja/Admin/controller/DictionaryController.php @_rejestracja/template/partial/Index/Index.tpl @_rejestracja/template/partial/Index/IndexSent.tpl @_rejestracja/Admin/template/partial/Calc/Reg.tpl @_rejestracja/Admin/template/partial/Calc/RegEdit.tpl
<acceptance_criteria>
AC-1: Dictionary Contains Registration Phrase Set
Given the new dictionary seed runner has been executed
When an admin opens /_rejestracja/Admin/Dictionary/Index
Then the phrases introduced for the XXXV conference registration flow are listed as editable Polish dictionary entries
AC-2: Public Form Uses Dictionary Phrases
Given the registration form is rendered
When the page displays invoice, talk/poster, participation, lodging, day choice, diet, and price labels
Then those visible strings are produced through the existing translation plugin instead of hard-coded template text
AC-3: Confirmation And Admin Views Use Dictionary Phrases
Given a registration has been submitted
When the confirmation page/email and admin list/detail views render participant data
Then repeated labels, yes/no values, missing-value text, participation option labels, and diet labels come from the dictionary
AC-4: Existing Registration Behavior Is Preserved
Given the phrase refactor is complete
When the modified PHP/Smarty templates are linted and searched
Then no database field mappings, pricing calculations, form field names, POST values, or payment status behavior have changed
</acceptance_criteria>
Task 1: Seed dictionary entries for registration phrases _rejestracja/sql/2026-04-24-registration-dictionary-phrases.sql, _rejestracja/sql/apply-2026-04-24-registration-dictionary-phrases.php Create an idempotent dictionary seed for `mf_dictionary` covering phrases from the previous plan and additional related repeated phrases found during review: - invoice/participant/institution/talk sections and field labels - `Tak`, `Nie`, `brak`, payment status values - fee labels, payment deadline labels for 03.10.2026, net/gross/VAT labels, total-to-pay labels - participation labels: full conference, one day with lodging, one day without lodging, selected-day prompts, selected-day output labels - lodging/accompanying-person labels and diet labels - consent labels and admin action/status labels only where they are part of the registration views Use stable keyword names for new implementation-focused phrases where the raw Polish phrase would be awkward or repeated with markup, for example `registration_participation_full`, `registration_yes`, `registration_no`, `registration_missing`, `registration_diet_standard`, `registration_fee_discount_2026`. Preserve existing dictionary keys already used in templates (`agree1`, `agree2`, `agree_title`, `klauzula_ceny`, `send`, etc.) and do not duplicate them under new names unless a different visible phrase is needed. The PHP runner must skip existing `(keyword, lang)` rows and create Polish replacements for at least `pl`; if the app exposes other langs through `Router::GetArrayLang()`, create placeholder replacements consistently with `Dictionary::CheckAndAdd`. Avoid schema changes; this is data seeding only. Run `php -l _rejestracja/sql/apply-2026-04-24-registration-dictionary-phrases.php` and inspect the SQL/PHP phrase list for no duplicate keywords. AC-1 satisfied: seed files can populate all planned registration dictionary phrases without modifying schema. Task 2: Convert public registration form and confirmation output to dictionary phrases _rejestracja/template/partial/Index/Index.tpl, _rejestracja/template/partial/Index/IndexSent.tpl Replace hard-coded visible text introduced or touched by plan `01-01` with `{translate word='...'}` or `{'...'|translate}`: - form headings and labels not already translated, especially invoice heading, referat/poster radio labels, fee option labels, participation options, selected-day prompt, lodging/accompanying-person labels, diet labels, `Jaka?`, and conference price label - confirmation headings/labels and repeated values (`Tak`, `Nie`, `brak`, participation option labels, diet labels) Keep technical values unchanged (`full`, `one_day_lodging`, `one_day_no_lodging`, `1`, `2`, posted field names, radio values, JavaScript IDs/classes). For Smarty `replace` chains, translate replacement values with preassigned local variables if inline modifier expressions become hard to read. Do not change pricing arithmetic, dates, selected-day values, or persisted participant fields in this task. Search the two files for the target hard-coded Polish phrases and confirm remaining literals are dates, DB values, CSS/JS text, or legacy content intentionally out of scope. AC-2 and the public portion of AC-3 satisfied. Task 3: Convert admin registration list/detail display to dictionary phrases _rejestracja/Admin/template/partial/Calc/Reg.tpl, _rejestracja/Admin/template/partial/Calc/RegEdit.tpl Replace hard-coded registration-related labels and display values in the admin registration list and detail/edit views: - participant, institution, talk/poster, amount/payment, consent, participation, diet, and payment status labels - `Tak`, `Nie`, `brak`, participation option labels, `standardowa/specjalna`, edit/delete/cancel/save button text where these are in the registration views Preserve admin routes, action names, form field names, payment status option values, delete confirmation behavior, and table/layout structure. Do not refactor unrelated admin modules or compiled template cache. Search the two admin templates for the target hard-coded registration phrases and confirm remaining literals are structural/admin legacy text outside this plan or values that must remain technical. Admin portion of AC-3 and AC-4 satisfied.DO NOT CHANGE
_rejestracja/controller/IndexController.phpform processing and persistence logic_rejestracja/core/model/MfParticipant.class.phpand_rejestracja/core/_model/MfParticipant.class.php- Existing pricing values, form field names, POST values, participant DB columns, and payment status values
_rejestracja/_Admin/temp/compile/*and_rejestracja/temp/compile/*- Third-party libraries and CKEditor assets
SCOPE LIMITS
- This plan only dictionary-enables registration phrases from the recent registration update plus obvious repeated labels in the same registration views.
- Do not translate all legacy admin UI globally.
- Do not alter the admin dictionary UI itself beyond using it as the target for seeded phrases.
- Do not fix unrelated mojibake or old conference-year text unless it is directly in a phrase being moved to dictionary.
<success_criteria>
- New phrase seed is idempotent and ready for deployment.
- Registration phrases are visible/editable in the dictionary after seed execution or page render.
- Public form, confirmation output, admin list, and admin detail use dictionary translations for the targeted phrases.
- Existing registration behavior from phase 1 remains unchanged. </success_criteria>