search

pebble-dev / mobile-app

Rebble device companion app for iOS and Android
Apache License 2.0
149 stars 25 forks source link

Add internationalization #61

Closed matejdro closed 3 years ago

matejdro commented 3 years ago

Currently all strings in the app are hardcoded english. At some point, we should add https://flutter.dev/docs/development/accessibility-and-localization/internationalization to the project.

matejdro commented 3 years ago

Supposedly this one is a bit easier: https://pub.dev/packages/easy_localization

DreadBoy commented 3 years ago

I can start working on this. Sooner we do this, easier it's going to be, once there are 100s of hardcoded strings, it's going to be nightmare to do it.

Are we going to bundle locales with an app or download them via network? I have experience with easy_localization and while it's really good package for bundled locales it falls short for online locales.

matejdro commented 3 years ago

I don't think we plan on downloading locales over the internet. What do you think @piggehperson?

DreadBoy commented 3 years ago

Also, are we going to allow users to select their locales? We could read default locale from device and use that or we could have settings where users can choose their language in app.

AliceGrey commented 3 years ago

I think we should follow the default Android behavior of the language being based on the devices language. Also I think we should bundle all of the localizations with the app. Downloading them adds unnecessary complexity and infrastructure in my opinion.

AliceGrey commented 3 years ago

P.S. Rebble currently has a Crowdin setup for Cobble for when the time comes. We can link it to automatically open PR's for localization like we already do with the Sideloader app.

DreadBoy commented 3 years ago

I think we should follow the default Android behavior of the language being based on the devices language. Also I think we should bundle all of the localisations with the app.

I agree on both accounts. 👍 I'm just not sure how do we handle missing or similar locales. Let's say we bundle en and es locales with an app and user's primary locale is en_US. Should we recognize this as en? I suppose we do. What if we bundle en_US and en_GB and user's locales are en_AU (primary) and en_GB (secondary)? I suppose we should look through all user's locales until we find one we bundle and fallback to first bundled one only we don't find any match? Or even worse. Our bundle contains en_US, en_GB and es_ES, user's locales are en_AU and es_ES. Do we stop at first similar match (en_US) or continue searching in case we find exact match? Answer to this isn't straightforward, I fear. :( If we stop at first similar locale, UI will be in user's primary language but potentially incorrect country. If we try to find exact match, we might show UI in user's secondary or tertiary language but it will precisely what she wants. I lean towards 1st options.

AliceGrey commented 3 years ago

I think Android natively handles some of those concerns. Not exactly sure how that works out in flutter though.

AliceGrey commented 3 years ago

I think it's probably best to just match the first language. Country matching is nice but it'll be really difficult to get localization for each individual country without paying for a localization service. If we match language and country that's a bonus but I'm not sure that's something we need to stress too much at this point. For the Sideloader, of the current ~1000 active users, there are only ~15 languages I've seen users have.

AliceGrey commented 3 years ago

Currently our top languages are(in order): English German Russian French Japanese Itaian Spanish (Mexico) Polish Spanish(Spain) Thai