As we approach the first beta release of farmOS 2.0, it seems like a good time to begin thinking about translation/localization! A number of people have expressed interest in helping with various languages, so I thought it might be worth creating a forum topic to organize the effort.
There is still significant work being done on frontend features in the 2.x branch, so more strings that need translation will be added over the coming months. But I think if we spend some time establishing a process for contributing translations in parallel it will put us on a good track moving forward.
If you are interested in contributing translations, please subscribe to this topic! If you have experience with Drupal localization, and would like to help lead this effort, comment below! All help is welcome!
Here is the official tracking issue, which we can use for tracking specific development steps as they are identified: [META] farmOS 2.x Localization [#3159886] | Drupal.org - This forum topic can be for general discussion and strategy.
A good first step IMO is to write documentation for how to contribute translations, which we can include on https://docs.farmos.org.
We may want two separate documentation pages: one for how to contribute translations, and one for how to deploy/host farmOS with translations. There will often be overlap between the two audiences, I imagine, but keeping them separate feels like a good long-term way to organize things.
We are in the process of writing documentation for how to contribute translations, and I would like to give one final review of the current English strings, to make sure we are satisfied with them. So stay tuned - we will update this topic as things develop.
Hi guys,
good to see Beta out now. I already deployed it on one of our servers. When I showed it to our farmer, his first question was can we translate it to german. So I translated everything to german yesterday (maybe not perfect but a start). In farmOS/Drupal it shows me 100% translation. But still, there are some English words. Like in the menus and even on the dashboard, all the asset names are still English.
Maybe I forgot something and someone can point me in the right direction.
Still, I attach the po-file if someone is interested
(I only found an upload for photos, so here is a temporary download link: farmOS-de.po)
Thanks for your answer @mstenta !
While searching for how to translate in Drupal I found that you can somehow offer the translation to others but I had no closer look at it yet. Maybe I will do that tomorrow.
Would you mind opening a bug report?
Sure, I will also do that tomorrow + some more details and screenshots.
I´m not sure if this is really a bug (at least on your side), when coming back to it this morning some of the words that were not translated yesterday, are now translated. I clicked through some menus which were still in English and all of a sudden Drupal showed new text that needed to be translated. A really weird behavior if you ask me. I maybe should add that I made all of the translations through the UI and not in a file (if that’s possible).
I think that then not all of the farmOS stuff is translated because I have some modules disabled. Maybe I will set up an environment with all the farmOS modules enabled and add the translations that are left.
Oh interesting! I wonder if it was a caching issue. Are you familiar with clearing the Drupal cache? There are two ways to do it: go to /admin/config/development/performance and click the button, or use the Drush command line interface: drush cr.
Maybe I will set up an environment with all the farmOS modules enabled and add the translations that are left.
That would be great! Don’t worry about getting everything perfect - a first pass of the most obvious strings is better than nothing!
I just gave it a try and cleaned the cache (through the UI) and you won´t believe what happened. It made it worse again. So all the things that are for example on the dashboard (and even the things in the farmOS menu) are English again.
When I go to an overview for example all the animals, the properties are mostly translated.
As you can see some parts are still translated some are not.
Now I hope that I´ve done nothing completely wrong
When setting up the new environment I will reimport my po-file and see what happens in the dev environment then. Maybe we will get some new data out of that.
Wow that’s weird! Well @SirSundays how about we work on this in the GitHub issue so we can leave this forum topic more general? I added a comment over there for the “Add asset” / “Add log” links…
This module will essentially serve as a way to configure all the necessary stuff within farmOS to enable localization. We still need to add documentation with setup instructions, as well as documentation for how to contribute translations. Help is welcome!
As expected, there will be a number of individual strings we need to fix in the farmOS code to make them translatable too. So that will be the initial process: get this farm_l10n module working and merged, identify and fix places where strings are not being translated, and then document how to use/contribute translations. Then we should be ready to start enlisting the help of translators in earnest!
Hey all, working on a quick form in a client project that has a “Wind direction” field with the main cardinal directions (North, South, etc) and ordinal (inter-cardinal, Northeast, Southeast, etc) directions hard-coded in strings as options. * Terminology source Cardinal direction - Wikipedia
I’m translating these in their module, but is this something that farmOS core could provide, even if not used by any core module? Or does this turn into a big can of worms?
That raises a good question @paul121 - to rephrase: should farmOS (core) provide a list of strings for translation even if it doesn’t use them directly? The benefit of doing this is that they would be translated before they are needed. The cost is maintaining/translating a list of strings that may never be used.
Good question. Modules can register any string they like to be translated by using t('My string'). “Providing a translation” means this string must then be translated, exported to a langcode.po file, and optionally hosted/distributed somewhere like localization.drupal.org.
Any module can use a translation once the string is translated, even if the string was first used/provided by another module. So for contrib it would be convenient if “farm related” strings came pre-translated.
Another benefit of this is that it could “centralize” the translating a process. Instead of someone needing to install all contrib modules, they could just install farmOS core to translate even a subset of the strings exclusively used by contrib. Although this would still never be perfect as contrib modules will often (if not always) have their own unique strings that would need translating as well.
Yeah, for that reason it would make sense to only introduce strings once 1 or 2+ “common” contrib modules use them. But at that point, would it be expected that many installations would have the modules, and thus the translations would already be available?
In other words, if we can’t decide on what strings farmOS core should provide until there is sufficient usage/agreement, would the problem have already solved itself?
It feels to me like providing translations for strings we don’t provide ourselves would be a can of worms to maintain, and to your point would only provide marginal benefit because there will be plenty of other strings in contrib modules that will need to be translated anyway.
Can modules provide their own translations?
Indeed they can! I haven’t tried this, but my understanding is that a module can provide ./translations/[langcode].po files for the strings it uses. This is an alternative to uploading them to localize.drupal.org (which has other benefits), and is useful for custom/contrib modules that are not hosted on drupal.org but which still need translations.
