Add localization support #10

Caellian · 2025-06-04T21:02:42Z

Makes algorithmic read text.lang and use appropriate keywords/control words for the currently used langauge. Idea is that contributors could add their languages over time as they need them (with en being fallback).

If the document is multilingual this makes it very straightforward to use appropriate language based on current context.

I also added support for syntax like:

Fn.with((en: "floor", hr: "pod"))

Locales besides en and hr were generated using an LLM as placeholder values. If locale is not in the file, or an empty string for some kw, then english is used as fallback. For functions it's english, then first value, and none if empty dictionary was provided.

Signed-off-by: Tin Švagelj <[email protected]>

quachpas

Thank you!! It looks great. I like the localized keyword syntax. I think it can be refined a bit further. I have left some starting comments if you are willing to adress them.
Thank you once again

algorithmic.typ

quachpas · 2025-06-05T20:50:44Z

algorithmic.typ

+  }))
+})
+#let l(kw) = context {
+  let lang = text.lang


I think it's better if the default lang stays "en". We can add a lang parameter to specify.

This is to avoid breaking old documents?

I'd prefer a version bump because specifying lang for every algorithmic block feels off given that there's #set text(lang: "en") which is per-documentation meant to be used for "[...] all other things which are language-aware".

I gave it a try, it's a breaking change anyway because of:

#let Terminate(lang: none) = (smallcaps(localize("terminate", lang: lang)),) #let Break(lang: none) = (smallcaps(localize("break", lang: lang)),)

which were previously values instead of functions.

This is to avoid breaking old documents?

Yes, for now let's avoid breaking the default behaviour. We can keep everything to english keywords without respecting text.lang. For now, this PR is going to be merged as a patch release.

I'd prefer a version bump because specifying lang for every algorithmic block feels off given that there's #set text(lang: "en") which is per-documentation meant to be used for "[...] all other things which are language-aware".

Let's aim that for 2.0.0. I think it's best if we have a larger language support before a major release

I gave it a try, it's a breaking change anyway because of:

As for Terminate and Break, it's fine because that should return the same result.

quachpas · 2025-06-05T20:51:13Z

algorithmic.typ

+  let lang = text.lang
+
+  if type(kw) == str {
+    let kws = locale.at(lang, default: locale.at("en"))


In which case, a default here is not necessary. It's better to throw an error if the corresponding lang does not exist.

Localization always falls back to default text. Using english isn't seen as wrong in most cases because even in LaTeX customizing algorithmx isn't all that common.

If we assume explicit lang argument approach, I'd like to be able to specify a language even if it isn't supported yet and for the document to compile. If the text isn't localized, then I'd switch to "en" if I don't want it to change in future, or keep "de" if I want the proper locales to be used once they're supported.

With using the current text.lang this is obviously the only reasonable approach.

If the text isn't localized, then I'd switch to "en"

I'd rather algorithmic panic on that point. This is unexpected behaviour (and implicit) to fallback to english keywords if the lang input is not supported yet. Hence, removing the default from at. Don't bother with making it a nice panic, I can make that later.

locale.csv

- Rename `l` function to `localize`. Signed-off-by: Tin Švagelj <[email protected]>

Signed-off-by: Tin Švagelj <[email protected]>

quachpas

Thanks for the edits. This is looking well. Can you try to run the tests? I believe lang should be "en" by default, not none.

quachpas · 2025-06-07T06:29:15Z

algorithmic.typ

@@ -53,34 +78,38 @@
    ..table_bits
  )
 }
-#let algorithm-figure(title, supplement: "Algorithm", inset: 0.2em, ..bits) = {
+#let algorithm-figure(title, supplement: none, inset: 0.2em, lang: none, ..bits) = {


supplement should be "Algorithm" by default, not none.

none means none is specified explicitly, so it'll use default localization. This way you can still specify something like "Derp" without the rest of the code trying to localize that.

In docs you'd state the default is "Algorithm" as you did previously.

EDIT: Right, with keeping "en" the default, doing this doesn't make the API nicer. I'll make a commit addressing this review, as it's isolated to these changes it should be straightforward enough to simply revert it for 2.0.0.

quachpas · 2025-06-07T06:30:21Z

algorithmic.typ

+  }))
+})
+#let l(kw) = context {
+  let lang = text.lang


This is to avoid breaking old documents?

Yes, for now let's avoid breaking the default behaviour. We can keep everything to english keywords without respecting text.lang. For now, this PR is going to be merged as a patch release.

I'd prefer a version bump because specifying lang for every algorithmic block feels off given that there's #set text(lang: "en") which is per-documentation meant to be used for "[...] all other things which are language-aware".

Let's aim that for 2.0.0. I think it's best if we have a larger language support before a major release

I gave it a try, it's a breaking change anyway because of:

As for Terminate and Break, it's fine because that should return the same result.

quachpas · 2025-06-07T06:32:45Z

algorithmic.typ

+  let lang = text.lang
+
+  if type(kw) == str {
+    let kws = locale.at(lang, default: locale.at("en"))


If the text isn't localized, then I'd switch to "en"

I'd rather algorithmic panic on that point. This is unexpected behaviour (and implicit) to fallback to english keywords if the lang input is not supported yet. Hence, removing the default from at. Don't bother with making it a nice panic, I can make that later.

Made "en" the default locale and `localize` panic on missing locale as requested. Signed-off-by: Tin Švagelj <[email protected]>

Caellian · 2025-06-10T21:21:32Z

Done

Signed-off-by: Tin Švagelj <[email protected]>

quachpas · 2025-06-23T12:05:05Z

@Caellian, thank you for the modifications. I have yet to look at them, but I will definitely find the time in the coming weeks. Thank you again!

quachpas · 2025-07-09T09:01:39Z

@Caellian I checked out your branch and tried to run the tests, but they don't run. Please test your PR so that I can review it! Thank you.

Caellian added 2 commits June 4, 2025 22:48

Add localization support

8fe3c98

Signed-off-by: Tin Švagelj <[email protected]>

Support called function name localization

70b0c8f

Signed-off-by: Tin Švagelj <[email protected]>

quachpas self-requested a review June 5, 2025 07:02

quachpas self-assigned this Jun 5, 2025

Fix none return when l is applied to unsupported types

1fbe31c

Signed-off-by: Tin Švagelj <[email protected]>

quachpas requested changes Jun 5, 2025

View reviewed changes

Caellian added 2 commits June 6, 2025 01:25

Switch csv with a typ file

62619b3

- Rename `l` function to `localize`. Signed-off-by: Tin Švagelj <[email protected]>

Improve handling

3061eda

Signed-off-by: Tin Švagelj <[email protected]>

quachpas force-pushed the feat/locales branch from 8ce64ac to 3061eda Compare June 7, 2025 06:41

quachpas requested changes Jun 7, 2025

View reviewed changes

Hardcode english locale as default to remove context

127a088

Made "en" the default locale and `localize` panic on missing locale as requested. Signed-off-by: Tin Švagelj <[email protected]>

Merge remote-tracking branch 'upstream/main' into feat/locales

da69e54

Signed-off-by: Tin Švagelj <[email protected]>

Caellian requested a review from quachpas June 10, 2025 21:27

Add localization support #10

Are you sure you want to change the base?

Add localization support #10

Conversation

Caellian commented Jun 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

quachpas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caellian Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

quachpas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caellian Jun 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Caellian commented Jun 10, 2025

Uh oh!

quachpas commented Jun 23, 2025

Uh oh!

quachpas commented Jul 9, 2025

Uh oh!

Uh oh!

Caellian commented Jun 4, 2025 •

edited

Loading

Caellian Jun 5, 2025 •

edited

Loading

Caellian Jun 7, 2025 •

edited

Loading