Translation in farmOS 2.x: Wierd behavior

[SirSundays]

Some of the farmOS stuff is not translated, even when there is a translation in the po-file.
After a while, some of the translations seem to appear in the UI, but there are also some appearing in the list of missing translations after visiting their corresponding site.

I have some more details here on the forum: https://farmos.discourse.group/t/farmos-2-0-translation-localization-l10n-initiative/922/7?u=sirsundays

The only two important things that seem to be missing in the translation are on the dashboard the button in the top right corner "Add asset" and "Add log". When I click on them the right translations are displayed in the top row.
I would expect that these are the same as the ones displayed on the button. But still one is working while the other is not.

Screenshots

Here is what I mean. Everything is now translated (maybe it was because of a new browser startup (only tried to reload with clear cache)), except the button in the top right. Drupal shows 100% translation. Can't be trusted in my opinion.

Desktop (please complete the following information):

• Browser Firefox
• Version 2.x-beta1

But this doesn't seem to be a major bug so don't give it too much of a priority.

-- Jan

[mstenta]

Thanks @SirSundays!

I'll admit I'm very inexperienced with Drupal 8/9 localization, so we'll be learning together. :-)

I may have a hunch what's causing this problem, though... if you would be willing to test it?

Here is the line of code that is defining the "Add asset" and "Add log" (also "Add plan") link titles:

farmOS/modules/core/ui/action/src/Plugin/Derivative/FarmActions.php

Line 39 in 8530496

$this->derivatives[$name]['title'] = 'Add ' . Unicode::ucfirst($type);

We may just need to change that line to:

$this->derivatives[$name]['title'] = $this->t('Add :entity_type', [':entity_type' => Unicode::ucfirst($type)]);

Note that this also requires adding use StringTranslationTrait; to the top of the class definition so that it looks like this:

class FarmActions extends DeriverBase {

  use StringTranslationTrait;

  /**
   * {@inheritdoc}
   */

Would you like to give that a try and see if it works?

[mstenta]

Oh and be sure to clear the cache after making that change so that it takes effect!

[mstenta]

Regarding the strange behavior you described in the forum (https://farmos.discourse.group/t/farmos-2-0-translation-localization-l10n-initiative/922/12)... it might be time to ask some people who are more experienced with Drupal localization. :-)

There is a #multilingual Drupal Slack channel - might be worth asking the pros over there!

[SirSundays]

Ok, so let's stick to this issue regarding the strange behavior.
I will try out the things you posted above for translating the add button.

But regarding the other issue with the strange behavior (some part of it at least): I found this answer on StackExchange: https://drupal.stackexchange.com/a/271391
So it seems to me that this is how it works. But also it is really bad, because custom error messages could be not translated. They would have to appear first. Are there some of these in farmOS?

I will do some more research on the not appearing translation tho.

[mstenta]

Oh @SirSundays this actually reminds me... someone told me about a core Drupal translation issue that sounds familiar to what you described. I am looking for the issue link, but if my memory serves me it had something to do with using a language other than English as the site's default. Can you try something? Try setting the site default to English, but then override to German in your user profile. And then see if this cache clearing issue still happens? I'll see if I can find the link...

[paul121]

I found this answer on StackExchange: https://drupal.stackexchange.com/a/271391

This answer is correct. You need to "register strings" in the desired language before they can be translated. See "Register a string with the Translate interface UI" at the bottom: https://www.drupal.org/docs/multilingual-guide/translating-site-interfaces

[mstenta]

Ok here is the one that I was thinking of: https://www.drupal.org/project/drupal/issues/2806009

There are a few more that I found in the process though, which we may also need to be aware of:

• https://www.drupal.org/project/drupal/issues/2905295 (maybe the same as above?)
• https://www.drupal.org/project/drupal/issues/3136820
• https://www.drupal.org/project/drupal/issues/2910353

That last one makes me wonder if this is related to farmOS's core farm_update module - which reverts config when the cache is cleared... :-/

[mstenta]

@SirSundays FYI the weekly farmOS dev call is in 1 hour, if you are interested in joining! Happy to talk about some of this stuff. https://meet.jit.si/farmos-dev

[SirSundays]

@mstenta I will see if I can arrange that somehow. I would also be interested in talking about this.
@paul121 Ah thank you. I didn´t know that you really have to register strings.

[SirSundays]

Thanks @SirSundays!

I'll admit I'm very inexperienced with Drupal 8/9 localization, so we'll be learning together. :-)

I may have a hunch what's causing this problem, though... if you would be willing to test it?

Here is the line of code that is defining the "Add asset" and "Add log" (also "Add plan") link titles:

farmOS/modules/core/ui/action/src/Plugin/Derivative/FarmActions.php

Line 39 in 8530496

$this->derivatives[$name]['title'] = 'Add ' . Unicode::ucfirst($type);

We may just need to change that line to:

$this->derivatives[$name]['title'] = $this->t('Add :entity_type', [':entity_type' => Unicode::ucfirst($type)]);

Note that this also requires adding use StringTranslationTrait; to the top of the class definition so that it looks like this:

class FarmActions extends DeriverBase {

  use StringTranslationTrait;

  /**
   * {@inheritdoc}
   */

Would you like to give that a try and see if it works?

This works! I think then I found another place where we need to apply this.

[mstenta]

Excellent! Would you like to organize some changes (including this one) into a pull request? If you are familiar with that process... if not I'm happy to as well!

[mstenta]

@SirSundays I just started a PR for adding a farm_l10n module, which would serve to enable the modules we know we'll need and provide some default configuration: #475

Just a work-in-progress... haven't really tested it much yet... but maybe worth taking a look at and trying out if you have a chance!

[mstenta]

@SirSundays: @paul121 and I stayed on the call for a bit after you left (that's when we started the farm_l10n module) and played around a bit with the language options in Drupal, with the nasty core issue in mind. In the process of reviewing the "Detection and selection" options (/admin/config/regional/language/detection/selected) a potential workaround popped to mind: leave the default language as "English" but change the "Selected language" configuration to the language you want.

The help text for the "Selected language configuration" (/admin/config/regional/language/detection/selected) suggests as much:

Changing the selected language here (and leaving this option as the last among the detection and selection options) is the easiest way to change the fallback language for the website, if you need to change how your site works by default (e.g., when using an empty path prefix or using the default domain). Changing the site's default language itself might have other undesired side effects.

I spent some time this evening reading through the core issue thread, and this comment seems to suggest the same workaround: https://www.drupal.org/project/drupal/issues/2806009#comment-14009513

I've been using this workaround for the past 3 years without any problems. I advise it for all single language sites. Default language: English, All lanuage detections off, Selected language (default detection): Dutch.

So... since this core issue seems to be a thorny one, which may not get resolved soon, I wonder if our best approach is to recommend that users do not change the default language from English, but instead change the "Selected language configuration" as described above.

Maybe we could even enforce this in our farm_l10n module, by removing the ability to change the default language, and providing an easier way to change the "Selected language". It would be a "hack" / workaround, but maybe it would serve our needs. 🤷

[SirSundays]

@SirSundays I just started a PR for adding a farm_l10n module, which would serve to enable the modules we know we'll need and provide some default configuration: #475

Just a work-in-progress... haven't really tested it much yet... but maybe worth taking a look at and trying out if you have a chance!

I see that you are still doing some work on it, so maybe I will try this out next week and have a closer look at it then.

[mstenta]

Yes it needs a bit of work. I'll let you know... :-)

[SirSundays]

So... since this core issue seems to be a thorny one, which may not get resolved soon, I wonder if our best approach is to recommend that users do not change the default language from English, but instead change the "Selected language configuration" as described above.

I tried this on my running system. Seems to work fine, but the metrics and menus are not translated. (This worked once for me, don´t know why) All the subpages are tho. After loading my translation the once under configuration translation (the extra module we mentioned in the meeting yesterday) were already translated so this is already fine.

After clearing the cache, I faced the same issue again. So all the farmOS translations were gone. After reporting the po-file it was back in the state as mentioned before. So most of the strings translated but not the metrics and submenus.

Another big issue I faced:
When using "Detection and selection" and then choosing "URL", the user can choose that different languages have different URLs. So English may have example.com/en and another language may have example.com/de. If the user is using this option it breaks some of the farmOS links. So stuff like the locations page (/location) or add asset (/asset/add) is not working anymore. I disabled the feature again.

Should I put this in another issue or leave it here?

BTW I created this issue, so we can collect all the words which need context:
Issue 476: Translation / Localisation - Words / Strings that need context

Yes it needs a bit of work. I'll let you know... :-)

Nice.

[mstenta]

I will do some local testing myself with the PO file you created (thanks again!) - I'll see if I can replicate the cache clearing issue and figure out what's causing it...

When using "Detection and selection" and then choosing "URL", the user can choose that different languages have different URLs. So English may have example.com/en and another language may have example.com/de. If the user is using this option it breaks some of the farmOS links. So stuff like the locations page (/location) or add asset (/asset/add) is not working anymore. I disabled the feature again.
Should I put this in another issue or leave it here?

Yea I think this detection method does not make sense for farmOS. It is intended more for website. My plan with the farm_l10n module is to automatically disable "URL", and enable "Session", "Browser", and "User". Those will provide all we need I think. No need to open an issue for it.

[mstenta]

@SirSundays Can you try something? Enable the "Session" detection method. This allows you to add ?language=de to the end of your URL to enable translations in that language, and if it is above the other methods in the list it will take precedence. Can you try adding that parameter to your homepage URL, and then clear the cache and see if the issue still happens for you?

I'm wondering if the cache clear is affecting the detection logic. I am testing locally with the ?session method, and I'm not sure the issue is happening for me. So if it is indeed the detection that is affected by cache clear, then maybe we have a clue to investigate...

[SirSundays]

Yea I think this detection method does not make sense for farmOS. It is intended more for website. My plan with the farm_l10n module is to automatically disable "URL", and enable "Session", "Browser", and "User". Those will provide all we need I think. No need to open an issue for it.

Ah ok. So I had the same settings without "Session".

After now adding the session, calling it manually once via example.com/?language=de, and clearing the cache from drupal most things were translated correctly. Even after another cache clearing, everything was still fine.

The only thing missing is the menu links. Here is a screenshot of it:

Just asking something that is not totally obvious to me: How would a new user go about this? Would he then need to call the route once and that's it or do we need to make some kind of automation for it? Because if he manually needs to go there, that wouldn't be user-friendly you know?

[mstenta]

After now adding the session, calling it manually once via example.com/?language=de, and clearing the cache from drupal most things were translated correctly. Even after another cache clearing, everything was still fine.

OK good to know! A step in the right direction...

The only thing missing is the menu links. Here is a screenshot of it:

Ok yea I am seeing that too - as well as a number of other places like Metrics. I think once we get the overall localization config working, we can start digging into each case like this individually to debug them. Some might be related to config translations (which I haven't enabled locally yet myself), and others may be farmOS code that needs to be tweaked.

How would a new user go about this? ... Because if he manually needs to go there, that wouldn't be user-friendly you know?

Yea agreed - we need to make this easy. That's what I hope the farm_l10n module can do. Ideally we can instruct users to just "Turn on the farmOS Localization module, then go to [a simple form we provide] and change your default language" - and it will configure everything for them.

Before we can do that we just need to understand how everything needs to work. That's what I'm learning right now. :-)

[mstenta]

PS: I think I found a way that we can prevent new users from changing the default language when they install farmOS, by adding langcode: en to farm.info.yml: https://github.com/farmOS/farmOS/blob/2.x/farm.info.yml

I haven't tested this yet, but in theory it will prevent the language selection screen from showing during the installation steps.

[SirSundays]

as well as a number of other places like Metrics.

To be honest the Metrics are fine. That`s all german you see there 😄

Some might be related to config translations (which I haven't enabled locally yet myself), and others may be farmOS code that needs to be tweaked.

I already have an idea, what could be the problem with the menu. I think it has something to do with the config translation and that the default language is still English.

Before we can do that we just need to understand how everything needs to work.

Let´s hope the just won`t take that long 😉 But I think we are already on a good path.

I haven't tested this yet, but in theory it will prevent the language selection screen from showing during the installation steps.

I should be able to test this today.

[mstenta]

I just pushed a commit to my 2.x-l10n branch that will automatically configure the enabled language detection methods when it gets installed. If you'd like to try this module out now it will be a good starting place! I would be curious if you still see any issues with cache clearing on a fresh install with this. Try doing it without explicitly using ?session... I disabled the URL selection, and enabled Session, User, and Language selection (but left Browser disabled for now... not sure we need that).

The next things I'd like to do in it are:

1. Disable changing the default language from English.
2. Add a helper form for changing the "Selected language".

[SirSundays]

If you'd like to try this module out now it will be a good starting place!

I would really like to try this out now, but to be honest I have no real idea how to get from the repo to a working farmOS instance 😅
I only used the docker images until now and did some mods there. Do I just need to build the images with the Dockerfile or do I need to run build-farmOS?

If could just push me in the right direction I would be very happy to test it out.

[mstenta]

I just pushed some new updates/functionality to that module, described here: #475 (comment)

If could just push me in the right direction I would be very happy to test it out.

Of course! Did you use the dev environment setup instructions originally? https://farmos.org/development/environment/

If so, then you should have a docker-compose.yml file, and in the same directory there is a www directory. That is the full farmOS codebase, bind-mounted as a volume into the Docker container.

If you go into ./www/web/profiles/farm you will be in the farmOS repository directory (with a .git directory that has an origin which maps to https://github.com/farmOS/farmOS.git).

To get my 2.x-l10n branch locally, open a terminal in the ./www/web/profiles/farm directory and run the following commands:

git remote add mstenta https://github.com/mstenta/farmOS.git
git fetch mstenta 2.x-l10n
git checkout 2.x-l10n

Then, you should be able to go to /admin/modules in your browser and find the new "farmOS Localization" module. Enable that and it should do the following:

• Configure your language detection rules automatically
• Add a /farm/settings/language form that lets you set the default language
• Prevent you from changing the site's default language in /admin/config/regional/language and show a warning message with a link to /farm/settings/language.

With that branch checked out, if you try to install farmOS again from scratch it should ALSO skip the language selection screen, so you can't pick a different language during install. But you should see the new "farmOS Localization" module in "Optional modules".

[SirSundays]

Of course! Did you use the dev environment setup instructions originally? https://farmos.org/development/environment/

Thanks :D Thats what I did.

That is the full farmOS codebase, bind-mounted as a volume into the Docker container.

Ah ok I noticed that before but I thought its was done differently. Thanks for clearing this up.

So basically whenever I want to test out a branch I get the repo in there test stuff and that's it?

Then, you should be able to go to /admin/modules in your browser and find the new "farmOS Localization" module.

Works!

Configure your language detection rules automatically

Works. Session, User, and the predefined language are selected. (in that order)

Add a /farm/settings/language form that lets you set the default language

So the first part works. I have a new dropdown menu where I can select the default language. But it seems to me that it doesn't have any effect. The user language is still the preferred language. Let's say my user language is german. If I then select English in the dropdown it has 0 effects.
Should this already work or is this just a placeholder? I´m not sure right now 😅

Prevent you from changing the site's default language in /admin/config/regional/language and show a warning message with a link to /farm/settings/language.

Works too.

Now I have shut down the docker containers. Deleted the db-folder and started it up again. Drupal shows me the installation screen. The first thing is "Choose language". Do I need to delete something else or is it just not working as intended?
When I´m then at the point "Install modules" it shows me "Translation/localization features". So this is working right?

[mstenta]

So basically whenever I want to test out a branch I get the repo in there test stuff and that's it?

Generally speaking, yes... although this will only work for branches that do not need to add additional Drupal modules/libraries (eg: additions to composer.json dependencies). That requires a full rebuild. But for simple branch/PR testing this will work!

I have a new dropdown menu where I can select the default language. But it seems to me that it doesn't have any effect.

Hmm actually the same thing happened to me... (even using ?language=de does not change it)... so there must be something missing still... Hmm...

Drupal shows me the installation screen. The first thing is "Choose language". Do I need to delete something else or is it just not working as intended?
When I´m then at the point "Install modules" it shows me "Translation/localization features". So this is working right?

Bummer - I was hoping the "Choose language" screen would not be displayed. I guess I need to look into that a bit deeper too...

Thanks for testing these things! And thanks for the PRs you opened! I will review when I have a chance (maybe not today - we just got a foot of snow here!)

[SirSundays]

(even using ?language=de does not change it)

Actually, this worked for me. Not everything again, some strings were missing, but most of the stuff got translated and I could change between en and de.

Thanks for testing these things!

It´s great to learn new stuff here on the way.

maybe not today - we just got a foot of snow here!

No problem. I will also be out for a couple of days. I have to get back to do some work on the hardware I develop at the moment, but I will probably be there at the monthly call next week. So see you there.

[mstenta]

Drupal shows me the installation screen. The first thing is "Choose language". Do I need to delete something else or is it just not working as intended?

Ah I think I see what I did wrong. The langcode: en line in farm.info.yml needs to be a child of the distribution: section. I force pushed that last commit to make that change. You can update with the following (run in the ./www/web/profiles/farm directory):

git fetch mstenta 2.x-l10n
git checkout 2.x-l10n
git reset --hard 2.x-l10n

Hopefully that works to hide the "Choose language" step in installation. 🤞

I have a new dropdown menu where I can select the default language. But it seems to me that it doesn't have any effect.

I will investigate this next...

[mstenta]

Hmm OK so I think I know what's happening... and it relates to the workarounds we're employing...

Our detection/selection rules basically specify that the chosen language should come first from the User, and then Selected language (setting aside the Session one for a moment). However, the User language is already set to "English" for any users that were created before translations were enabled. And when new users are created, they default to the "Site default" language... which will always be English.

If you edit your user profile, you'll see that it is set to English (even after changing the "selected language"). But changing that DOES change the site's translations as expected.

So, I think we need to do two things:

1. Include a step in our setup instructions to manually change the User language for any users that already existed.
2. Override the "Create user" form to set the default value for new users to the value of the Selected language configuration.

Re 1: we may be able to provide an option to "Automatically set existing users language to the default" when the selected language is changed. This can be a follow-up IMO.

As an aside, I think I will actually disable Session by default, since it is only really necessary for testing purposes. An admin can decide to enable it if they need to. We really only need User and Selected language for normal functioning by default.

[mstenta]

OK! All of these are done in my 2.x-l10n branch now:

Include a step in our setup instructions to manually change the User language for any users that already existed.

Override the "Create user" form to set the default value for new users to the value of the Selected language configuration.

And:

provide an option to "Automatically set existing users language to the default" when the selected language is changed.

That last one will optionally run a batch operation to change the "preferred langcode" of all existing users. It is disabled by default, so the admin needs to explicitly enable it to perform the operation.

Getting there! :-D

[mstenta]

Here is the draft documentation for enabling translations: https://github.com/mstenta/farmOS/blob/2.x-l10n/docs/hosting/localization.md

@SirSundays I think that should cover everything from the perspective of someone who just wants to enable and download existing translations.

Next step will be to document how to contribute translations (and how to create local translations like you have been doing). I have a draft "work in progress" commit that creates the file for this. I just need to familiarize myself with the steps we need to document...

[SirSundays]

Hopefully that works to hide the "Choose language" step in installation. 🤞

This works. It could be a bit confusing maybe for new people if the "choose language" step is just skipped tho. I found on the internet this bit:

  /**
    * Implement hook_install_tasks_alter().
    */
   function multilanguage_install_tasks_alter(&$tasks, $install_state) {
     // Set default site language to English.
     global $install_state;
     $install_state['parameters']['locale'] = 'en';
     // Hide 'Choose language' installation task.
     $tasks['install_select_locale']['display'] = FALSE;
     $tasks['install_select_locale']['run'] = INSTALL_TASK_SKIP;
   }

I really don't know if it works but I found, that this hook is already implemented in the farm profile, so maybe it would be worth a look. Not needed but would be cool. (Had some problems testing it because the farm profile wouldn't update immediately after saving and rebuilding the cache, while I was in the installation process.)

Unfortunately, I can't test any further right now, because I get this error at the last installation step:

Error
The website encountered an unexpected error. Please try again later.
InvalidArgumentException: The form argument \Drupal\farm\Form\FarmModulesForm is not a valid form. in Drupal\Core\Form\FormBuilder->getFormId() (line 197 of core/lib/Drupal/Core/Form/FormBuilder.php).

Drupal\Core\Form\FormBuilder->getFormId('\Drupal\farm\Form\FarmModulesForm', Object) (Line: 227)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\farm\Form\FarmModulesForm', Object) (Line: 952)
install_get_form('\Drupal\farm\Form\FarmModulesForm', Array) (Line: 618)
install_run_task(Array, Array) (Line: 571)
install_run_tasks(Array, NULL) (Line: 119)
install_drupal(Object) (Line: 48)

I tested this with a completely fresh instance of farmOS with the beta1 docker containers. If you didn't encounter this problem I will take a look at it on Wednesday.

@SirSundays I think that should cover everything from the perspective of someone who just wants to enable and download existing translations.

Yeah, I think so too. I will further work on the german translation this week (hopefully).

Here is the draft documentation for enabling translations:

Looks good to me. Maybe we should let someone have a look at it that doesn't know anything about this whole translation stuff. So I got it right that we will take the official route with localize drupal service and not go the download and import route, right?

Next step will be to document how to contribute translations (and how to create local translations like you have been doing).

Did you already have a look at this process? I really don't know if I made it like it should be done 😅

[mstenta]

It could be a bit confusing maybe for new people if the "choose language" step is just skipped tho.

Hmm perhaps.

We could certainly user hook_install_tasks_alter() to add our own language selection step! I will leave this for a potential follow-up, since I probably won't have time to dig into it in the 2.x-l10n branch right now, and it feels like that branch is at a good "minimum viable product" stage right now. Maybe we can review/merge that and then open a new issue about improving the installation process.

Unfortunately, I can't test any further right now, because I get this error at the last installation step
I tested this with a completely fresh instance of farmOS with the beta1 docker containers. If you didn't encounter this problem I will take a look at it on Wednesday.

Oh hmm! I'm not sure what is causing that. I have not encountered it.

So I got it right that we will take the official route with localize drupal service and not go the download and import route, right?

I think localize.drupal.org should be the "ultimate" goal - but I know that there is a process to getting strings accepted there, so I am also open to using PO files in the meantime! Maybe we can start a forum topic just for people to contribute/exchange PO files like the one you created. I think that will allow people to get started much faster, while we go through the process of getting them accepted in localize.drupal.org.

Did you already have a look at this process? I really don't know if I made it like it should be done 😅

Not really! This is all new to me too. It seems like you have figured a lot of it out correctly. I could probably learn a thing or two from you actually.

Would it be easy to summarize the steps you went through? Even just in these comments... I would be happy to take that and formalize it into the docs - as a first pass at least.

Is it basically something like this?

1. Go to /admin/config/regional/translate
2. Select the language you want to add translations for
3. Filter to "Only untranslated strings"
4. Fill in empty boxes and click "Save translations" (on each page)
5. Export to PO file via Export tab

The parts that are still fuzzy in my mind are:

• Config translations
• "Registering" strings?
• The process of getting strings into localize.drupal.org

[SirSundays]

it feels like that branch is at a good "minimum viable product" stage right now.

I agree with you on that.

Oh hmm! I'm not sure what is causing that. I have not encountered it.

Hm okay, I will debug it then 👍

Would it be easy to summarize the steps you went through? Even just in these comments... I would be happy to take that and formalize it into the docs - as a first pass at least.

I can make something up in the next couple of days.

Is it basically something like this?

To be honest yes 😄
I will have to do some research on registering strings tho.
In my case, the config translations were already done after I did the "normal" translations. But I will also have a look at this too.

The process of getting strings into localize.drupal.org

I hope it wont be that hard 😅

[mstenta]

it feels like that branch is at a good "minimum viable product" stage right now.

I agree with you on that.

I took the PR out of "draft" status and requested @paul121's review. Let's get this into 2.0.0-beta2! 😄

[mstenta]

@SirSundays I merged #475! I think that we can close this issue now as well, since the "weird behavior" is resolved. However you and I can continue to use this thread for discussion if we need to. Alternatively we can start a new forum topic or just communicate in the farmOS chat room - whatever works! Thanks again for your help identifying this issue, testing all this stuff, and contributing to the localization efforts!!

[mstenta]

@SirSundays after the dev call we found this module, which might be helpful for us: https://www.drupal.org/project/potx

It it used by localize.drupal.org to extract all strings from projects hosted on drupal.org. It seems that contributing translations directly to localize.drupal.org will bypass the need to "register strings" locally. But maybe this module would be helpful locally too for finding strings? Worth a try...

[mstenta]

@SirSundays are you finding that the asset and log types listed under the Records menu are being translated? Or not? I'm helping another user and the asset and log types in the menu are still in English even though they are translated in other parts.

I'm wondering if maybe our code needs to be tweaked to translate those menu items:

• farmOS/modules/core/ui/views/src/Plugin/Derivative/FarmViewsMenuLink.php

  Line 35 in e834a8c

  'title' => $info['label'],

• farmOS/modules/core/ui/views/src/Plugin/Derivative/FarmLogViewsTaskLink.php

  Line 25 in e834a8c

  'title' => $info['label'],

(there may be others like that)

[SirSundays]

@mstenta Actually yes they are not translated currently, but I remember they were one time before I cleaned cache. The config is also translated for me. So that isn't the big problem.
But it's really weird so I think we would need to have a closer look at it.

[mstenta]

Ok good to know - I think I know the fix for it... I'll take a look...

[SirSundays]

Had some busy 2 weeks but I could find a spare hour today to start getting back to translating.

So as I found out, as a new member of the german translating group, I do not translate stuff right away but I give suggestions and a moderator then has to approve it. (Found here.)
So I think it may take a while for all suggestions to be approved.
What I don't know: When I translated everything but nothing is approved, can I still download a po file with all the suggestions and share it with others?
Then we could make a repo with all translations for farmOS, as long as the translations are not approved on localize.drupal.

I already translated a lot but there are still ten pages with 50 each. So I definitely did not discover/register everything when I was doing everything in farmOS itself. 😂

I also created an issue in the german group saying that I´m currently translating everything farmOS related, so maybe that can give a boost to getting all the suggestions approved.

I think I can join the dev call this week. Would be nice if we could spare another 10 minutes, to talk about translations.

[mstenta]

FYI I created an official bug report to track the menu translations specifically: https://www.drupal.org/project/farm/issues/3262752

[SirSundays]

FYI
One of the guys from the german translation group made a whole 20-minute video on how to correctly translate farmOS.
I didn't watch it fully yet but I think with the youtube subtitles you guys could watch it too!

https://www.youtube.com/watch?v=JT9fIdJlc9E