Greek language support

[MinosChatzidakis]

Hi,
I would like to propose that Greek is also added to the list of supported languages. I could personally take this on as I am a native speaker, given that I receive the necessary directions.

[shockalotti]

Yes please, and thank you for offering. A native speaker is genuinely valuable here: every non-English locale we ship is currently a machine draft with no native review, so Greek would be the first one somebody actually checked. If you take this on I will note that in the docs rather than carrying the usual caveat for it.

Adding a language is one file. No Go, template or frontend change is needed, because init() globs the directory and everything else reads SupportedLocales().

1. Create internal/i18n/locales/el.json. el is the right BCP-47 code, and the filename must be canonical lowercase, the same way pt.json is.
2. Copy internal/i18n/locales/en.json and translate the values. Keep every key, keep the key order (it keeps diffs readable), and keep printf verbs (%s, %d, %q) intact. Reordering is fine with indexed verbs (%[2]s); dropping one is not.
3. dow_short_*, month_short_*, date_format and clock_format are data keys, not code, because Go has no locale date tables. Match CLDR; the tests cross-check you against Intl.
4. Run go test ./internal/i18n/. Three guards will tell you exactly what is wrong: key parity, printf-verb parity (using fmt as the oracle), and the CLDR date-table check.
5. Eyeball it with go run ./cmd/calnode and ?lang=el on a booking page and the manage page. Long words overflowing buttons is the usual surprise, so check mobile width too.

The surfaces translated are the booking page, manage page, embed widget, the four emails and the calendar invite. The admin UI and the video room stay English-only.

Your CLA is already on file from earlier contributions, so there is nothing to sign this time.

If the file is easier to build by editing a copy of en.json alongside a native speaker read-through, that is exactly the shape that reviews well. Looking forward to it.

[MinosChatzidakis]

Understandable. The main differences compared to english is that in greek the words are usually longer and we often use two or three words to say the same thing we would with just one in english. So your note on words overflowing is highly likely to happen. Is there anything I should do in case I notice that ?

[shockalotti]

Good question, and the short answer is: don't bend the Greek to fit. If a longer string breaks a layout, that is our bug, not a translation problem, and I would rather fix it once.

The spots where long words actually show up first:

• The info panel on the booking page is a fixed 240px column on desktop (it stacks on mobile). The event name, host name and the metadata lines live there, so that is usually the first thing to look wrong.
• The month label in the calendar header sits in a fixed 240px strip.
• The buttons are full width, so they absorb length well. The primary button and the manage/reschedule controls are the ones worth checking on a narrow window.

If you see something clip, wrap awkwardly or push the layout around, tell me:

1. the key name from en.json (e.g. email_manage_button),
2. which surface (booking page, manage page, one of the emails, the embed widget), and
3. roughly how wide the window was. A screenshot is the fastest.

Then we fix the CSS or the layout once, and every long-word language benefits, not just Greek.

Two things that will help you while writing:

• If Greek wants the arguments in a different order, use the indexed verbs (%[1]s, %[2]s) instead of %s. Those are supported and exist precisely so a translation can reorder.
• Plural forms: the templates use a simple two-form mechanism. If a concrete Greek sentence reads wrong because of it, say which key and I will handle it on the server side rather than make you approximate.

Do not worry about the admin UI or the video room. They are English-only on purpose.

Either open an issue when you hit one, or just mention it in this thread. Both work.