Add multilingual translation support #23

New Issue

2026-07-23T21:52:18Z

jfig commented

2026-07-23 21:52:18 +00:00

Add internationalization support so the application can be used in multiple languages.

Requirements:

Introduce a centralized translation/localization system for user-facing text.
Support selecting the application language, with a sensible default language.
Ensure translated text covers labels, buttons, status messages, warnings, errors, and other visible UI text.
Make it straightforward to add additional languages without changing application logic.
Handle missing translations gracefully by falling back to the default language.
Preserve the existing layout when translated strings are longer or shorter.

Add internationalization support so the application can be used in multiple languages. Requirements: - Introduce a centralized translation/localization system for user-facing text. - Support selecting the application language, with a sensible default language. - Ensure translated text covers labels, buttons, status messages, warnings, errors, and other visible UI text. - Make it straightforward to add additional languages without changing application logic. - Handle missing translations gracefully by falling back to the default language. - Preserve the existing layout when translated strings are longer or shorter.

jfig referenced this issue

2026-07-23 21:53:52 +00:00

Add European Portuguese (pt-PT) translation #24

jfig commented

2026-07-24 13:03:14 +00:00

Repository analysis and implementation plan

The application is a small static OpenLayers client with its user-facing text concentrated in index.html and app.js. This can be delivered cohesively in issue #23; separate sub-issues would not create useful independent workstreams.

Plan:

Add a dependency-free centralized localization module with a stable message-key API, interpolation, plural handling, locale normalization, and English fallback.
Ship English and Portuguese (pt-PT) dictionaries covering static copy, dynamic statuses, warnings/errors, map-control tooltips, accessibility labels, feature dialogs, and map attributions.
Add a language selector, default from the saved preference or browser language, persist changes, and set the document language.
Format locale-sensitive values with the active locale and add wrapping safeguards for longer translated content.
Document how to add a language and add tests for detection, persistence, interpolation, fallback, and dictionary completeness.

Implementation status:

The plan is implemented in the local worktree. npm test passes all 6 localization tests, JavaScript syntax checks pass, the new module is served correctly by the local server, and the GeoServer capabilities proxy still responds successfully. No sub-issues are needed.

Repository analysis and implementation plan The application is a small static OpenLayers client with its user-facing text concentrated in `index.html` and `app.js`. This can be delivered cohesively in issue #23; separate sub-issues would not create useful independent workstreams. Plan: 1. Add a dependency-free centralized localization module with a stable message-key API, interpolation, plural handling, locale normalization, and English fallback. 2. Ship English and Portuguese (`pt-PT`) dictionaries covering static copy, dynamic statuses, warnings/errors, map-control tooltips, accessibility labels, feature dialogs, and map attributions. 3. Add a language selector, default from the saved preference or browser language, persist changes, and set the document language. 4. Format locale-sensitive values with the active locale and add wrapping safeguards for longer translated content. 5. Document how to add a language and add tests for detection, persistence, interpolation, fallback, and dictionary completeness. Implementation status: The plan is implemented in the local worktree. `npm test` passes all 6 localization tests, JavaScript syntax checks pass, the new module is served correctly by the local server, and the GeoServer capabilities proxy still responds successfully. No sub-issues are needed.

jfig commented

2026-07-24 13:08:02 +00:00

Follow-up validation found and fixed a Docker packaging omission: index.html referenced i18n.js, but the Dockerfile did not copy that file into the image. This caused XProI18n is not defined and stopped map/layer initialization.

i18n.js is now copied into the image, the local container has been rebuilt, and HTTP checks for the page, localization module, application script, and GeoServer capabilities endpoint all return 200. A deployment regression test now verifies that every application script referenced by the page is included by the Dockerfile. All 7 tests pass.

Follow-up validation found and fixed a Docker packaging omission: `index.html` referenced `i18n.js`, but the Dockerfile did not copy that file into the image. This caused `XProI18n is not defined` and stopped map/layer initialization. `i18n.js` is now copied into the image, the local container has been rebuilt, and HTTP checks for the page, localization module, application script, and GeoServer capabilities endpoint all return 200. A deployment regression test now verifies that every application script referenced by the page is included by the Dockerfile. All 7 tests pass.

jfig closed this issue

2026-07-24 14:47:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jfig/xprov#23