Danish currently sits at 54.4% coverage across the web editors (10,701 of 19,687 keys), rank 40 of 45 locales. For comparison, fr, ru, de, ro, el and pt are all at 99.7%. I would like to close that gap.
I saw #199 and #200 splitting Polish into mobile and desktop surfaces, and I intend to follow the same structure unless you prefer otherwise. For Danish that would be roughly:
Desktop surfaces — ~7,377 missing keys plus ~658 that currently hold the English string
Mobile surfaces — ~1,609 missing keys plus ~30 holding English
Given the volume, I would rather deliver this in stages than drop it all at once. My plan is to start with presentationeditor/main (1,579 missing, 55.8% coverage) as a self-contained first batch, and continue from there.
A few questions:
Is the desktop/mobile split from #199/#200 the structure you prefer, or would you rather have smaller per-component PRs?
Is anyone else already working on Danish? I would like to avoid duplicated effort.
Is there a terminology or style guide per language? I plan to use the Microsoft Danish localization style guide, which is the most widely used reference for Danish software terminology and builds on Retskrivningsordbogen from the Danish Language Council.
When new source strings are added to en.json, are translators notified, or is it up to contributors to spot the gap?
For context: I work in local government IT in Denmark. We run Nextcloud and are rolling out Euro-Office, so plan to test changes on a live instance with real documents.
AI disclosure: I expect to use Claude Opus 5 to assist with the process and to propose translations. I will read through and review and verify each string myself and take responsibility for every line. :-)
Danish currently sits at 54.4% coverage across the web editors (10,701 of 19,687 keys), rank 40 of 45 locales. For comparison, fr, ru, de, ro, el and pt are all at 99.7%. I would like to close that gap.
I saw #199 and #200 splitting Polish into mobile and desktop surfaces, and I intend to follow the same structure unless you prefer otherwise. For Danish that would be roughly:
Desktop surfaces — ~7,377 missing keys plus ~658 that currently hold the English string
Mobile surfaces — ~1,609 missing keys plus ~30 holding English
Given the volume, I would rather deliver this in stages than drop it all at once. My plan is to start with presentationeditor/main (1,579 missing, 55.8% coverage) as a self-contained first batch, and continue from there.
A few questions:
Is the desktop/mobile split from #199/#200 the structure you prefer, or would you rather have smaller per-component PRs?
Is anyone else already working on Danish? I would like to avoid duplicated effort.
Is there a terminology or style guide per language? I plan to use the Microsoft Danish localization style guide, which is the most widely used reference for Danish software terminology and builds on Retskrivningsordbogen from the Danish Language Council.
When new source strings are added to en.json, are translators notified, or is it up to contributors to spot the gap?
For context: I work in local government IT in Denmark. We run Nextcloud and are rolling out Euro-Office, so plan to test changes on a live instance with real documents.
AI disclosure: I expect to use Claude Opus 5 to assist with the process and to propose translations. I will read through and review and verify each string myself and take responsibility for every line. :-)