OFF's localization is so bad

1

I’m sorry for this post, but it will be a summary of my pain, because really, this is the worst realization of localization feature I ever seen. It works even worse than machine translation on usual websites.

I will start from OpenPrices. It has the best localization between all OFF projects, because right now it just doesn’t have it. But even here there is a problem… For some reason, all product links lead to French site of OFF.

firefox_9AJC8m3CfN
firefox_9AJC8m3CfN1761×1004 240 KB

Just why? I know that France is one of the most important countries because of huge number of contributors from there, but it doesn’t mean that this redirection should be to French website with French language as main for all users. And even in the foot links lead to “world.” domain

изображение
изображение1920×141 24.3 KB

If we started this theme already. Why is there so overcomplicated prefix system of OFF’s sites and their languages? As far as I understand it now, it has a next structure:

[country-code].[lang_code].openfoodfacts.org

But I wasted many weeks before I realized what is the reason that I need to log in too often and why the annoying constant language change happen, when I go between different projects and products… I just didn’t think that I can have redirections to different country/language subdomains… And I can’t change this behavior.

I guess, I got that idea, why it is implemented in this way. Possibly, you wanted to separate products that are sold in different countries and show only them to me. Again, it took me some days before I realized why products that were modified or were added by me not always are displayed on some subdomains I used because I didn’t think it can be the reason because it wasn’t specified anywhere. But then there is a new question: just for why to add this isolation? In most cases I just need to find some product in all database. And even if I want to do some more specific search query, why just can’t it be search filter option or setting option?

If it will be just just a filter option on one domain, it will also significantly simplify your localization problems. You won’t need to implement this over-complicated language hierarchy, where every country should have a separate subdomain with separate and unique list of available languages and it will solve the problem of constant redirections between different subdomains and languages.

I think that we should just have one site openfoodfacts.org with these 4 options and that’s it:

  • interface language
  • preferred language for displaying parameters that cannot be translated (as product name), maybe it should be order of languages in descending order of preference
  • language used for adding/editing products by default; if I use Swedish interface in USA it doesn’t mean that products will have Swedish names and descriptions.
  • country filter for my searches (only if I need it and it should not be chosen by default); something as “show only products that are relevant for country ['x]”

In current realization, that is used now, again, there are plenty problems with redirections, logins and translation too (how for instance do you choose, that some language should/not be used for some country subdomain?).

And you even started to use similar logic in your mobile app! But there are other localization problems in it.

  • Interface language is used for adding and editing products by default. It is a strange and annoying decision, because as I mentioned earlier, they should not be the same thing. I can want to use Kazakh interface language in USA because it is just more comfortable for me, but products still are in English mostly. But even if I chose other language, when I use “Take more pictures”, for some reason first of these pictures automatically will be used for the interface language (that I switched from it earlier).
  • Categories are not really useful outside English and maybe French languages.
  • It is not clear, how brand names should be added when they are in many languages.
  • It is not clear why there are plenty variants how weigh/quantity info can be added “1L, 1l, 1 liter, 1 литр etc”. Again, it makes hard to localize it
2

Hello Libra,
I will provide some answers to your feedback one point at a time.

I will start from OpenPrices. It has the best localization between all OFF projects, because right now it just doesn’t have it. But even here there is a problem… For some reason, all product links lead to French site of OFF.

We do have localization on Open Prices. You can go to the settings to change the language. If I remember correctly, we use the browser configured language when first loading the Open Prices website.

For some reason, all product links lead to French site of OFF.

That’s indeed a bug!

But I wasted many weeks before I realized what is the reason that I need to log in too often

That’s not the reason why you have to login again, the session cookie is available for all subdomains. I think it gets invalidated when we deploy a new version of the server, which I find infortunate as well.

But then there is a new question: just for why to add this isolation? In most cases I just need to find some product in all database. And even if I want to do some more specific search query, why just can’t it be search filter option or setting option?

It’s because most users prefer to have only products of their own countries, and not the full database. You can always use world subdomain if you want the worldwide database.

I agree that the current system is a bit complex for people who are not familiar with the project though!

1 Like
3

Thanks!

Right, my bad! I totally forgot about these settings, sorry! I changed them after my registration except for used interface language and forgot that they even exist. Looks fine now. Are these settings saved only locally in my browser and I need to set them every time on new device/browser, because I called to mind now that I already filled them?

OK, that has sense, that other people can prefer this behavior. But I was ready for it. My main point was about why this is made on subdomain level instead of setting this preference in account settings? I think it is over-complicated logic, because it generates so many annoying redirections between different domains and it is hard to control them all.

If it is just one domain, it has only 3-4 components:

  • products from country
  • interface language
  • default language for adding/editing products
  • preferred language for displaying parameters that cannot be translated

and these parameters will be used all the time by the system. And if I want I just can change search filter to “Whole world”. While the way how it is implemented now there are too many strange, nonstandard details, which I need to know all of them before comfort using. For instance:

  • How languages for every country are chosen? Why for instance, for Israel subdomain (https://il.openfoodfacts.org/) there are only 4 languages available for using: Hebrew, Arabic, Russian and English? Why can’t I use every language that I want to use as interface language? It should be popular language? Then how is it calculated? And still why is it even important? Why can’t I use Swedish for searching products in France if I want? Why is it limited? Or it is enough even 1 person who will request some language for adding? Then again it doesn’t have any sense, because you will need to add every language for every country. In addition, because of that you need to have separate list of available languages for every country subdomain and you need to control all these lists and support them separately.
  • If I suddenly found some non local product that I want to check, I need to know exact barcode which often is not specified on the Internet, because without it I can’t find this ‘foreign’ product in base of local products. In other case, I need to call to mind, that I need to change subdomain to other, search by product name on this other subdomain and after this search I need to keep in mind, that I should return it to my usual domain.
  • Because language defined by separate affix, I need to set it every time I change local search to global search or other local domain and try to return it after that.
4

On Open Prices, products links are localized to user country. Users can change their country in settings : https://prices.openfoodfacts.org/settings. For example, if I set it to Italia, all links point to https://it.openfoodfacts.org.

1 Like
5

I found and recognized that already after @raphael0202 's answer. Still, thanks for your response too!

6

Can you give us a few cases where there are such redirections? I haven’t experienced this issue myself.

Saving it in user settings could be a good alternative, with the benefits you list here (it’s easier to understand for users). There is however a major upside to having this subdomain-based system: for each country, there is a single subdomain in the user language, that is indexed by search crawlers. It ensures we have a good visibility on search engines.

How languages for every country are chosen?

We use the official languages of the country. I don’t know why we have English and Russian for il though. The language can be overridden in the subdomain if needed (although I agree it feels a bit hacky to do so).

1 Like
7

Hi, of course!

If I use language other than the main (https://il-en.openfoodfacts.org/ for instance English in Israel), every time I use Google search for finding products (which is preferable way for me because in-built OFF search is too slow, at least until search update), all pages in result will be only in default country language after redirecting. It means that every time I need to switch it to English interface manually anew.

If there are products, in which user country is not listed in “Countries where sold” field, then after search on OFF country subdomain I don’t get any relevant results and I need to click on “View results from the entire world” (all OFF interface is too huge, but this specific button is small and it is easy to ignore and don’t take attention to it XD), which redirects me to ‘https://world-xx.openfoodfacts.org/’ with same language. Maybe this is the reason why you don’t have this issue at all. Perhaps you are in some country, where almost all products are added to DB and to this list and they can be found with country specific search (French or USA I guess?). But I’m in a country, where most products still are not listed/added and it makes really hard to use OFF site, because on my main subdomain I can’t find almost anything, which is especially annoying because I know that all these products ARE in the database and this is one more reason why I stopped to use the in-built search. Because I just need to switch from country subdomain to global domain and vice verse without any real sense for that.
And, by the way, it is not clear at all that to make some products visible in a new country, you need to add this country to “Countries where sold” list. Because it is not specified anywhere on the website, that my search is limited by local products only and that this local product list is defined by “Countries where sold” data field. I wasted about one or two months before I even recognized it. Maybe there is some info about this stuff on Wiki page, but the Wiki has hundreds/thousands pages and it is strange to wait, that a new user/editor will read them all. Why all? Because it is impossible to know, where I need to read, when I don’t realize, it can be implemented in this way. And yeah, Wiki is not the best place for documentation…
Also after I was redirected to this global domain and finished to check this product, if I want to return to my country subdomain, the most intuitive way is using of top button with countries. But after I do that, I again get default country language in interface and should change it manually… So one more redirection

In addition, I like to compare same product in different languages and in current site implementation it is almost impossible mission. I need to guess, which languages can be available for some product and manually change [xx] part in https://world-xx.openfoodfacts.org/[product] to language codes, that I want to try to check. Very comfortable for using (it’s not :grimacing:). In the OFF app it is not perfect too, but at least I can do that.

Saving it in user settings could be a good alternative, with the benefits you list here (it’s easier to understand for users). There is however a major upside to having this subdomain-based system: for each country, there is a single subdomain in the user language, that is indexed by search crawlers. It ensures we have a good visibility on search engines.

It is not just easier, but must have in my opinion. Because the current realization is so non standard and difficult for understanding, that I’m not even sure I even saw this localization implementation before. It needs too much efforts and time to learn all details and nuances of this localization feature in OFF.

OK, after your explanation I see the logic behind this decision, but still I think it is too complicated logic. Even if I understand your desire to separate domains by countries, I don’t understand yet why languages are linked to country domains. For example, why can’t it work in this way: by default pages for https://ua.openfoodfacts.org/ are generated in Ukrainian for SEO reasons, but if a different interface language is set in settings, for this user this page will be displayed/regenerated in language, which this user wants to use? It will allow to drop this strange [country].[lang].openfoodfacts.org syntax and simplify it to [country].openfoodfacts.org or [lang].openfoodfacts.org only, which is much more spread and easy to understand.

And does it mean, that in the app it can be implemented, because the app content doesn’t have this SEO requirements?