feat(web): translations #9854

Manic-87 · 2024-05-29T14:59:26Z

See Discussion #1688

Ignore the hooks.server.ts and the changes to vite.config.js.
The en-EN.json I created manually.
The de-DE.json I created initially manually but it was filled by weblate.
fr.json was created by weblate.
What you see in those files is everything I entered into weblate just to test if it works.

Copy of my comment from the discussion:

So I did invest some time on this and I currently could display quite a few texts in different languages and also make use of weblate.
Disregarding the weblate portion, I want to make sure I'm on the right track about translatability of the web.

I added svelte-i18n as a dependency as it looked good to me (mind you, I don't have any experience with svelte, so I can't properly asses if this is actually good). This would be the first question: Is the usage of svelte-i18n ok or are there any concerns?
I started with the "page.svelte" files, took the hardcoded texts, moved them into a "en-EN.json" file and used the svelte-i18n functions to get the texts back. Regarding the structure of the file would be the next important question. For Android it's a flat list. For the web I thought about using a hierarchical structure as it, in my opinion at least, improves later readability/extendability.

This means my file currently would look like this for example:

page: {
  admin: {
    library_management: {
      error_create: "Unable to create library"
      ...
      ...
    },
    system_settings: {
      auth_settings_title: "..."
      auth_settings_subtitle: "..."
      ...
      ...
    }
  }
}

For components the top level would be "component". For stuff which is used more often like "Video" or "User" there would be a top level "common" and so on. In the svelte files you'd then use
$t(page.admin.user_management.error_create)
for example. For stuff with placeholders you'd use
$t(page.admin.user_management.error_create, {values: {placeholdername: placeholdervalue}}).
With the placeholders you can also use plurals, so instead of having two rules strings for ""Matched 1 item" and "Matched 10 items" there would only be one "ICU plural messages" Matched {count, plural, one {# item} other {# items}}

What do you think? Is this the correct way for you or should I go at it some other way?

web/src/lib/i18n/locales/de-DE.json

jrasm91 · 2024-05-29T19:28:26Z

This PR is about the technical aspects of translating the web, so please refrain from commenting about specific translations. Those can be dealt with independently of these changes. (The translation values will be managed through an external platform).

With that said, I think this looks really good so far. I wonder what would be the best way to move forward. Presumably we want to share translation strings between mobile and web. Personally, I prefer the flat structure as the hierarchy might become coupled with the implementation (code), which might easily change in the future. Also, I think translating the admin settings are a much lower priority than the sidebar, asset viewer, albums page, and the asset grid component, so maybe we start with those pages. I think it would be good to get a solid foundation and then merge it in, we can incrementally externalize translation strings in follow-up PRs, thus avoiding merge conflicts that inevitably come from long standing PRs.

midzelis · 2024-05-30T04:32:44Z

web/src/hooks.server.ts

+import type { Handle } from '@sveltejs/kit'
+import { locale } from 'svelte-i18n'
+
+export const handle: Handle = async ({ event, resolve }) => {


This is a good default. Using browser locale is a generally close to accurate. However, I do think we should only treat this as a default/fallback. I think there should be a account-setting that allows you to change the language for your user, overriding the browser locale.

I absolutely agree. This is in a early stage and I was just testing around until now so I didn't bother to also look into how I could achieve something like that.

there should be a account-setting that allows you to change the language

Strong agree, and ideally this setting works for the mobile app as well. @jrasm91 with the new user preferences this should be relatively straightforward right?

web/src/lib/components/forms/admin-registration-form.svelte

Manic-87 · 2024-05-30T07:38:17Z

Presumably we want to share translation strings between mobile and web.

I did look into that a bit with weblate. AFAIK you can have different file structures for different components. If you want to make it really easy you'd need to define a glossary (weblate can use existing translations as a glossary) and need to use the same keys for the same translations.
Meaning:
My en-EN.json file has the String share under common. Weblate interprets it as common.share. If the mobile translation file also would have a string with this key the translation of the glossary would be applied to both the web and mobile translation.
The translations for web and mobile could still be translated to something different, but apparently would be overwritten by the glossary translation if the glossary changes.
This would either mean the current translationkeys of the mobile would need to be changed to use . instead of _, or the web translations would need to use the same keys as the mobile version.
Both options aren't optimal in my opinion. Changing all translation keys on the mobile seems like an unnecessary effort. Using the same keys on the web as the mobile will sometimes be strange, e.g. control_bottom_app_bar_add_to_album. On the web the Add to album button is on the top and it's obviously not the app.
Also I think it is preferable to make use of these ICU plural messages and the mobile don't (or perhaps even can't?) use them.

Unfortunately I haven't found a way to tell weblate to connect a translation to a specific glossary item even if the keys differ or at least mark the translation as "To check" at least. But perhaps I just didn't find it.

Most important question how to proceed would be: How should the keys be defined as changing them later on will be a hassle, but I'm afraid this will lead to neverending discussions.
What could be done would be to just do the translations for the web in the manner I already started and when this is done little by little the strings and translations of the web and mobile could be consolidated. For example: Look at all occurences of "Cancel" and decide on a common key for both web and mobile (mobile currently has 8 occurences in the translation file by the way). This could already be taken into account for strings that exist in both.

jrasm91 · 2024-05-30T12:27:35Z

Yeah I think this is a good point. We should decide on our optimal format and start using that. The mobile app should migrate to it in the future as well.

I would prefer having the translations be somewhat independent of the code/UI though. We don't need "app bar" or "bottom sheet" in the key. I think a "cancel" key would probably be fine.

Manic-87 · 2024-06-02T09:28:29Z

I changed my approach a bit. Wrote a simple script to extract the strings from the files, automatically create keys and replace the occurences. The automatic creation of the keys I only did for strings of at most 4 words and just replaced whitespaces with underscores and made the string lowercased. So "Add to" has the key "add_to".
This worked reasonably well and the result you can see in my latest commit. There are a few hickups, which need to be fixed again, and obviously a lot of strings which weren't touched but in my opinion this should be a good starting point.

I added an automatically translated german file for testing purposes.

MickLesk · 2024-06-02T16:43:21Z

Looks good! Massive Update on source Code, Ive only briefly skimmed through it (the individual commits) and everything looks clean so far.

PS: the German translation is crappy :D

waclaw66 · 2024-06-03T09:29:29Z

A small correction of constant_rate_factor_(-crf) to constant_rate_factor_crf would be fine.
However many thanks for you huge effort, this will help to further widespread of Immich. Many users don't want/can use Immich in English.

Manic-87 · 2024-06-03T12:07:59Z

I extracted and replaced some more strings. As these are mostly longer sentences I just used "placeholder_X" for the key for now. I suppose these keys should be decided by you.
I also changed a few of the keys. There were multiple ones with parantheses or a minus. I removed those.

Big Question: How to proceed.

Do you want to merge the currently available stuff? If so, with or without the autotranslated german file? Personally, I wouldn't include it, because.... it's really really crappy and I only changed those which annoyed me the most (translation for cancel for example).
Do you want to wait until at least all occurences of "placeholder_X" are changed?
Do you want to wait until even more/all strings are translatable?

Currently translated at 100.0% (4 of 4 strings) Translation: immich/web Translate-URL: http://familie-mach.net/projects/immich/web/de/

Currently translated at 100.0% (4 of 4 strings) Translation: immich/web Translate-URL: http://familie-mach.net/projects/immich/web/fr/

Currently translated at 100.0% (18 of 18 strings) Translation: immich/web Translate-URL: http://familie-mach.net/projects/immich/web/de/

jrasm91 · 2024-06-03T12:31:06Z

I think it looks good so far. We probably could just commit the English values for now and then finish setting up weblate for other languages

…ew unnecessary replacements

bo0tzz · 2024-06-03T13:19:18Z

cc @alextran1502, is weblate just ready to go or do we need to prep anything more?

Manic-87 · 2024-06-03T13:20:25Z

FYI: I just rebased the branch to the current main branch of immich and also removed the german translation file.

bo0tzz · 2024-06-03T13:47:03Z

web/src/lib/i18n/locales/en-EN.json

+    "thirty_minutes": "30 minutes",
+    "one_hour": "1 hour",
+    "six_hours": "6 hours",
+    "one_day": "1 day",
+    "seven_days": "7 days",
+    "thirty_days": "30 days",
+    "three_months": "3 months",
+    "one_year": "1 year",


For fields like this, should we use plurals? Per https://formatjs.io/docs/core-concepts/icu-syntax/#plural-format (though I may have made a mistake here):

{"hour": "{count, plural, one {count day} other {{count, number} days}"}

And then using that like

{$_('hour', { values: { count: 3 }})}

Plurals are very welcomed, especially for non-germanic languages (e.g. slavic).

bo0tzz · 2024-06-03T13:47:45Z

web/src/lib/i18n/locales/en-EN.json

+    "thumbnail_resolution": "Thumbnail resolution",
+    "tone-mapping_npl": "TONE-MAPPING NPL",
+    "tone-mapping": "TONE-MAPPING",
+    "transcode_policy": "Transcode policy",
+    "two-pass_encoding": "TWO-PASS ENCODING",


I think there's some inconsistency in the use of casing here (and of toUpperCase where these values are used)

waclaw66 · 2024-06-03T13:50:25Z

Those placeholders can be named according previous label... welcome_message, placeholder_0 => welcome_message_desc

jrasm91 · 2024-06-03T16:42:20Z

I'll go ahead and finish cleaning up the translations and then merge this. Once merged, I'll configure weblate with the git integration and we can go from there.

…com>

jrasm91

Thanks for working on this!

danieldietzler

Thanks a lot for pushing this forward! :)

jrasm91 · 2024-06-04T17:14:26Z

web/src/lib/stores/preferences.store.ts

+export const lang = persisted<string | undefined>('lang', undefined, {
+  serializer: {
+    parse: (text) => text,
+    stringify: (object) => object ?? '',
+  },
+});
+


Dedicated preference

jrasm91 · 2024-06-04T17:14:52Z

web/src/lib/constants.ts

@@ -155,7 +157,7 @@ export const locales = [
  { code: 'en-TT', name: 'English (Trinidad and Tobago)' },
  { code: 'en-VI', name: 'English (U.S. Virgin Islands)' },
  { code: 'en-GB', name: 'English (United Kingdom)' },
-  { code: 'en-US', name: 'English (United States)' },
+  { code: 'en-US', name: 'English (United States)', loader: () => import('$lib/i18n/en-US.json') },


Languages are a subset of locales.

jrasm91 · 2024-06-04T17:15:16Z

web/src/lib/constants.ts

+export const langs = [
+  ...locales.filter((item): item is LanguageLoader => !!item.loader),
+  { name: 'Development', code: 'dev', loader: () => Promise.resolve({}) },
+];


Locales with loaders + development language (shows raw translation keys)

jrasm91 · 2024-06-04T17:16:09Z

web/src/routes/+layout.ts

+  for (const { code, loader } of langs) {
+    register(code, loader);
+  }
+
+  const preferenceLang = get(lang);
+
+  await init({ fallbackLocale: fallbackLang, initialLocale: preferenceLang || fallbackLang });
+


Load languages and default to preference or english if unset.

jrasm91 · 2024-06-04T17:17:01Z

web/src/lib/components/user-settings-page/app-settings.svelte

+  const handleLanguageChange = async (newLang: string | undefined) => {
+    newLang = newLang || fallbackLang;
+    $lang = newLang;
+
+    const previousLang = get(i18nLocale);
+
+    if (newLang === 'dev') {
+      await init({ fallbackLocale: 'dev', initialLocale: 'dev' });
+    } else if (previousLang == 'dev' && newLang !== 'dev') {
+      await init({ fallbackLocale: 'en-US', initialLocale: newLang });
+    }
+    $i18nLocale = newLang;
+  };
+


Handle language change (need to remove the english fallback to see the development keys)

MickLesk reviewed May 29, 2024

View reviewed changes

midzelis reviewed May 30, 2024

View reviewed changes

web/src/lib/components/forms/admin-registration-form.svelte Outdated Show resolved Hide resolved

root and others added 10 commits June 3, 2024 14:10

First test

e15b14d

Added translation using Weblate (French)

c316229

Translated using Weblate (German)

ba5a5af

Currently translated at 100.0% (4 of 4 strings) Translation: immich/web Translate-URL: http://familie-mach.net/projects/immich/web/de/

Translated using Weblate (French)

d949345

Currently translated at 100.0% (4 of 4 strings) Translation: immich/web Translate-URL: http://familie-mach.net/projects/immich/web/fr/

Further testing

976bded

Further testing

22aa9b3

Translated using Weblate (German)

f5b48d7

Currently translated at 100.0% (18 of 18 strings) Translation: immich/web Translate-URL: http://familie-mach.net/projects/immich/web/de/

Further work

caa0224

Update string file.

7f23bca

More strings

6177525

root and others added 9 commits June 3, 2024 14:39

Automatically changed strings

43632a4

Add automatically translated german file for testing purposes

0124c7a

Fix merge-face-selector component

a9396aa

Make server stats strings uppercase

b0efecc

Fix uppercase string

fac210b

Fix some strings in jobs-panel

8f331e4

Fix lower and uppercase strings. Add a few additional string. Fix a f…

b64f410

…ew unnecessary replacements

Update german test translations

2106278

Fix typo in locales file

8c926f4

Manic-87 added 5 commits June 3, 2024 14:40

Change string keys

16158c2

Extract more strings

89cb41d

Extract and replace some more strings

878021e

Update testtranslationfile

da44d17

Change translation keys

72f56a3

Manic-87 force-pushed the feature/weblate branch from 3497129 to 72f56a3 Compare June 3, 2024 12:46

Manic-87 added 3 commits June 3, 2024 14:53

Fix rebase errors

feaf47d

Fix one more rebase error

bd449ff

Remove german translation file

1f62ea9

bo0tzz reviewed Jun 3, 2024

View reviewed changes

Co-authored-by: Daniel Dietzler <[email protected].…

2c0953e

…com>

jrasm91 changed the title ~~Web translatability~~ feat(web): translations Jun 3, 2024

jrasm91 added the 🖥️web label Jun 3, 2024

jrasm91 added 2 commits June 3, 2024 17:41

chore: clean up translations

8909feb

chore: add new line

ea15271

jrasm91 approved these changes Jun 3, 2024

View reviewed changes

jrasm91 marked this pull request as ready for review June 3, 2024 21:44

chore: Merge remote-tracking branch 'origin/main' into pr/Manic-87/9854

3e0d3ad

danieldietzler approved these changes Jun 3, 2024

View reviewed changes

danieldietzler and others added 4 commits June 3, 2024 23:53

fix formatting

47e9757

chore: fixes

f9788d3

fix: loading and tests

a6296c2

merge: main

9e861f7

jrasm91 reviewed Jun 4, 2024

View reviewed changes

jrasm91 merged commit f446bc8 into immich-app:main Jun 4, 2024
22 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(web): translations #9854

feat(web): translations #9854

Manic-87 commented May 29, 2024

jrasm91 commented May 29, 2024

midzelis May 30, 2024

Manic-87 May 30, 2024

bo0tzz May 30, 2024

jrasm91 May 30, 2024

Manic-87 commented May 30, 2024 •

edited

Loading

jrasm91 commented May 30, 2024

Manic-87 commented Jun 2, 2024

MickLesk commented Jun 2, 2024

waclaw66 commented Jun 3, 2024

Manic-87 commented Jun 3, 2024

jrasm91 commented Jun 3, 2024 •

edited

Loading

bo0tzz commented Jun 3, 2024

Manic-87 commented Jun 3, 2024

bo0tzz Jun 3, 2024 •

edited

Loading

waclaw66 Jun 3, 2024 •

edited

Loading

bo0tzz Jun 3, 2024

waclaw66 commented Jun 3, 2024

jrasm91 commented Jun 3, 2024

jrasm91 left a comment

danieldietzler left a comment

jrasm91 Jun 4, 2024

jrasm91 Jun 4, 2024

jrasm91 Jun 4, 2024

jrasm91 Jun 4, 2024

jrasm91 Jun 4, 2024

feat(web): translations #9854

feat(web): translations #9854

Conversation

Manic-87 commented May 29, 2024

jrasm91 commented May 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Manic-87 commented May 30, 2024 • edited Loading

jrasm91 commented May 30, 2024

Manic-87 commented Jun 2, 2024

MickLesk commented Jun 2, 2024

waclaw66 commented Jun 3, 2024

Manic-87 commented Jun 3, 2024

jrasm91 commented Jun 3, 2024 • edited Loading

bo0tzz commented Jun 3, 2024

Manic-87 commented Jun 3, 2024

bo0tzz Jun 3, 2024 • edited Loading

Choose a reason for hiding this comment

waclaw66 Jun 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

waclaw66 commented Jun 3, 2024

jrasm91 commented Jun 3, 2024

jrasm91 left a comment

Choose a reason for hiding this comment

danieldietzler left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Manic-87 commented May 30, 2024 •

edited

Loading

jrasm91 commented Jun 3, 2024 •

edited

Loading

bo0tzz Jun 3, 2024 •

edited

Loading

waclaw66 Jun 3, 2024 •

edited

Loading