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)
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
- Main wishlist with previous analysis made by Maikel: Multilingual instances
- Project follow up page: [FEAT] Multilingual
As analyzed by Maikel, there are two tech solution for data translatability:
Estimated tasks done by Maikel:
- 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