Multilingual instances enable users of a single language to see all info in their own language

Software improvement 1-Voting Candidates
1

Problem statement

In multilingual instances which are now almost all instances (French used by Italians, Katuma that has already catalan and castellano and soon portuguese, UK for Welsh users, Can for French users) need their users to be able to use the platform so they need to view all info in their own language.

Interface is already mutilingual, the problem is with data, as described by Maikel here.

I propose in this icebox to reduce the work to the following scoped need:

an user selling or buying only in one language on a multilingual instance can view all data in their own language. Which means we only have to translate product categories, VAT names, shipping categories, product properties.

We can then plan a new work to make all the fields needed for enterprise users who address multilingual shoppers.

Affected users / customers

All enterprise users and shoppers using an instance not in their own base country/region (Portuguese users on Katuma instance, Italian users on French instance, Welsh users on UK instance, French users on Can instance)

Problem impact

Users get confused and have difficulties to use the software or to buy (for instance shoppers can’t use categories filters as they are not translated in their language)

Benefit in focusing on this

Move toward single instance strategy and increase the use possibility of OFN, so remove barrier to use for users who already want to use the OFN.

Links to more details

Potential solutions

As analyzed by Maikel, there are two tech solution for data translatability:

Estimated tasks done by Maikel:
The tasks:

  • Discuss data structure change with other developers (10h)
  • Add Globalize to the OFN project (2h)
  • Change model classes (5h)
  • Add initial database migration (5h)
  • Possible difficulties / conflict solving (20h)
  • Denote translatable fields (5h)
  • Add language switcher to the admin interface (6h)
  • Final testing and reacting to feedback (11h)
    Total: 64 hours
1 Like
2

@tschumilas I know it is not yet fully meeting your need, I’m trying to make a small step so that we can prioritize and move forward, as it seems now most instances are affected. Maybe everyone will think we need to do it fully all in once and not start only with some data, let’s see how people react! @Kirsten @danielle @Rachel ready for review. Maybe @luisramos0 or @maikel can tell if that’s more work to make all data we want translatable (like product name, description, etc.) or only the ones I mentioned. I think it is more work as there is some UX involved, about how I setup those descriptions in multiple languages as an enterprise user, which is not involved in the scope I propose here.

3

makes sense to me @MyriamBoure - certainly it’s those fields you have mentioned that are tripping me up in Germany

4

I agree its those fields - maybe also fee names? Are these picked up in transfex? (Sorry I get a bit confused re; what we call ‘data’ sometimes.)

5

I would say in next step @tschumilas as it’s same as shipping and payment method, fees names are set up by the hub so that can put them in their own language. If you talk about main fee names that display in price details these are already translated in Transifex as far as I know, they are not data. Ok so I’m moving that to ready to vote as seems no objection from the two reviews.

6

It would be good to translate one data structure at a time. Doing all at once introduces unnecessary risks. Let’s do it with the most important thing first, for example product categories. Everybody can then get used to how it works. I imagine that you use the language switcher to change languages and then rename the items which will affect only that language. Once we are confident that it’s the right solution, we can add the other data structures.

1 Like
7

Good Maikel so what I suggest is to keep the need scope as is, but in the story map, plan a first iteration to make sure we get the good solution on only one data (product categories) before moving forward and implementing it to others in a second iteration. Because we want to stay connected to needs, and translating only products category is not enough to answer the first level of need IMO. But I agree with you on how to proceed.

1 Like