2 posts tagged with "localization"

This post is mainly to share my experience about how I used GitHub actions to deploy my open-sourced flutter web app without exposing any secrets or API keys that are crucial to my application. This approach can be used for any frontend framework and not just flutter.

Building the frontend of your application seems much interesting but once you start integrating with your backend or services like firebase or supabase etc, You need to manage API keys, JSON files, or secrets for your app, and we often end up either hardcoding those confidential keys by some kind of encryption or even the pros hardcode it as plaintext and commit it to a public repo😆, which might put your application at risk.

I wanted to develop a vocabulary app that is open-sourced and at the same time, I wanted it to be secure and wanted to make sure the app gets deployed without exposing the keys. This vocabulary app uses supabase in the backend, which is a open-sourced firebase alternative that provides a serverless solution that can get up and running in less than 2 minutes. In order to access the supabase database, it provides us with few keys which are unique to your application basically anyone with those keys could access the database, So you have to make sure those keys are safely stored.

Problem There were two challenges to make the project publicly available on Github

I have stored all those confidential keys into my flutter app in a constant file and the application can fetch those keys from that file and the app works fine locally, But the problem comes when we want to push the code to GitHub, since we cannot expose the keys publically.

Another problem is that the app uses flutter-action by subosito which is basically a CI solution using GitHub actions that automatically runs a script and deploys my flutter webapp on each commit by running some build commands, You can find the complete script here. But it is obvious that the build would fail if it finds if any of the pieces of the code are missing from the repository (Our secret keys in this case)this means the app won’t get deployed.

Image showing the build script running on each commit on a master branch

Basically, these two things wouldn’t allow my app to be deployed securely.

Solution​

So for this Github Encrypted Secrets comes to the rescue if you go to any repository under settings you will see an option called secrets which basically allows you to store any sensitive information in your organization, repository, or repository environments which can be accessed in GitHub Actions workflows.

But there is another problem​

The problem is you cannot access those encrypted secrets in your application, had it been the case the problem would have been solved and I would have called it a day 👋🏻. I searched a little about it but couldn’t find any solution which will allow you to access the encrypted secrets but since we have been using this amazing Q&A platform for devs called “StackOverflow” which helped me get an answer. Here is that stackoverflow question that I asked and I got a simple and amazing answer to that. Thanks to this user Xamantra for the solution.

Tell me the solution​

The solution is to

1. encode your confidential file to base64 and store the encoded output to GitHub secrets.
2. In your GitHub workflow decode the encrypted secret and convert it back to a file and then run your build scripts.

It's that simple

Now you can add your confidential files to .gitignore and never push it to the repository since now you have GitHub encrypted secrets.

Show me how it's done​

Here is how we do it step by step

1. convert your secret file to base64 the file can be of any type. I had a dart file which has the api keys stored so convert it to base64 using this command

base64 lib/path/to/secrets.dart

This will give you a base64 string copy that string and add it to GitHub secrets as shown in the below picture.

2. Now in your workflow script before you run the build command decode the base64 and convert it back to file with the path where it needs to be created.

run: echo $YOUR_SECRET_KEY | base64 -d > lib/somedirectory/secrets.dart env: YOUR_SECRET_KEY: ${{ secrets.YOUR_SECRET_KEY }}

And that's it, gentlemen ! that is it! you will see your build running successfully and the app getting deployed to the web, safe and secure with open-sourced code.

But there is one more problem what if you delete your local repository how do you get back those keys which you never pushed to Github?

That is still a mystery to me apart from the manual decoding let me know if you have a solution to this problem. More on this later sometimes if I find a solution.

Here is a link to the repository in case you would want to check it out.

Repository:https://github.com/maheshj01/vocabhub

Successful Builds : https://github.com/maheshj01/vocabhub/actions

Thanks for reading till the end.

Have a great day!

flutter logo taken from flutter.dev

Lots of apps require support for multiple languages inorder to have engagements with different kinds of users and we don't want to miss our customers just because of a language barrier.

I just googled and found that (As per a 2017 report) out of 7.8 billion people only 1.35 billion people speak English so that's approx 1/7 th of the population that means if you developed a software that targets humans only 1 out of 8 people will be able to understand it. Whether they would like it or would be interested in your app that's a different question 😂? If you develop something with all the effort and if people don't understand it, it's of no use. So you have to make sure your app supports the language of your targeted regions, so for this, we have to make use of L10N (aka LOCALIZATION).

So coming to the point since this post is specific to Flutter our goal is to implement localization in our flutter app and The flutter team has well documented it here about it and also there are tonnes of other blog posts and videos which explains it very nicely. But there's a problem, All those approaches suggest you to hardcode the static strings in the app.

But what if you have to make some changes to those Strings after you have deployed the app to stores?

Or

what if you want to add support for a new language or remove an existing language support?

In such cases we will need to make changes in the code and even with a single character change in the code, you will have to rebuild and redeploy your app as flutter doesn't support hot update as of today, so updating an app seems daunting.So In this post, I am gonna show you How I solved this problem using the approach shown below in one of the production apps and wanted to share it with you. The approach I will show you is less of a solution and more of "naive" workaround, If you know how to work with HTTP Requests and maintain the state of the app with a provider, This would be a piece of cake for you. This will get the work done without making a single line of change in code once it is implemented(unless you want to add new localized Strings to the app). Unfortunately, I cannot show you that mobile app, but don't worry I have a sample application built for this blog post that uses this approach. To Give you a test of the sample application this is how it looks.

Lets Approach the solution​

The things that we localize in an app are basically strings, we Identify each string uniquely with a key, So basically the data that has to be dynamically changed is a JSON object. This JSON data would lie somewhere in your backend which could fetch using network request. You could also store it locally on your phone but remember we want a dynamic solution to update the languages during runtime. 

If we were to localize the app in Spanish the json object would look something like this.

{
  "Hi": "Hola",
  "grateful": "Gracias"
}

if we had multiple languages we could just change the values and keep the keys the same. And our consolidated JSON object would look like this.

{
"es":{ /// json object for spanish
  "Hi":"Hola",
  "grateful": "Gracias"
  },
"en":{ // json object for english
  "Hi":"Hi",
  "grateful": "grateful"
  },
"
/// few other languages if any
...
}

Alternatively, we could just have one JSON object in a single response, and to get a correct translation we could just pass a query param in a request to let the backend know that we are requesting a JSON object of a particular language and it would return you the correct translation object. so once we have this JSON object ready we could just make an HTTP request decode the response and display it on the UI, problem solved right? No. Also, don't forget the variables, we also have variables within our static strings which could be numbers, dates, and other types.

for instance, consider this flutter code

String toolKit = 'flutter';
String platform =. 'MacOs'
@override
Widget build(BuildContext context){
   return Center(
      child:Text("Hey, This app is built using $toolKit for $platform")
   );
}

so for such strings, we need to make sure these variables go within those translations strings coming from the JSON object in the right place. so for this, I wrote a simple function that does this given an input it produces the respective output.

input: Hey, This app is built using ${toolKit} for ${platform}.

Here's the function that does this for us.

so for the above input, we would invoke this method like this

localize(input,[toolKit,platform]);

Then it would return the output

output:Hey, This app is built using flutter for MacOs.

Also, remember the order of the arguments in the Argument list List<String> should be the same as they appear in the translation sentence.

And the last thing to remember is we should fetch these translations before the app starts in order to prevent any issues And show a loader or the app splash screen whatever you prefer. You can also make use of the shared preferences to store the user's language preference which can be used to fetch the correct language on the next app launch.

Let's build the sample app​

Now that you understand the approach (I assume) let's build the sample app. Since you are looking for a solution for localization I assume you know how to build layouts in flutter so I won't be covering that part. so let's create the flutter project and run this command in your terminal

flutter create .

Now add these dependencies in your pubspec.yaml, I have used the json_annotation and dev_dependencies just to generate the toMap and FromJson methods but these dependencies are not mandatory.

dependencies:
  flutter:
    sdk: flutter
  http: ^0.12.0+2
  json_annotation: ^3.1.1
  provider: ^4.3.3
  shared_preferences: ^2.0.4
dev_dependencies:
  flutter_test:
    sdk: flutter
  build_runner: ^1.10.13
  json_serializable: ^3.5.1

Now in the main.dart we need to import provider and wrap the MaterialApp in a consumer so as to rebuild the whole app when we change the language.

The LocaleModel class contains everything about localization which we are interested in and the Settings Class contains code related to changing the theme of the app, So let's focus on the LocaleModel class.

class LocaleModel with ChangeNotifier {
LocaleModel() {
   fetchTranslations();
}
Map<String, dynamic> _translations = {};
Map<String, dynamic> _selectedTranslation = {};
Locale locale;
Locale get getlocale => locale;
Map<String, dynamic> get translations => _selectedTranslation;
set translations(Map<String, dynamic> map) {
  _selectedTranslation = map;
  notifyListeners();
Future<void> fetchTranslations({String language}) async {
   try {
     language = await getLanguagePreferences();
     final response = await http.get(Uri.parse(translationsApi));
     if (response != null) {
        if (response.statusCode == 200) {
            final Map decoded = json.decode(response.body);
            _selectedTranslation = decoded[language ?? 'en'];
            _translations = decoded;
            notifyListeners();
         }
     }
   } catch (_) {
     print(_.toString());
     }
   }
  }
}

the constructor at the top invokes this function as soon as the app starts. Remember we have a multiprovider wrapped around in main.dart that's where this call comes from.

LocaleModel() {
   fetchTranslations();
}

This function basically makes a network request and stores the translations in the state of the app in these two Map Objects _translation and _selectedTranslation. The _translation holds the consolidated Map object (with All languages) that we discussed above and _selectedTranslation holds the strings of the current translation being shown in the app. we need _translation in order to fetch the translation on changing the language this prevents us from making an extra API call, we directly fetch it from the state and refresh the app without making the user to wait for the changes to take effect. Now let's see how we are making use of these translations

Let's take a look at the description for the User which has three parameters in city, state, country

red underlined variables used in the description of the user.

The description that we receive in the API response looks like this

And this is how we access this map object from _selectedTranslation. considering we have already instantiated localeModel like this in initstate to access the objects of LocaleModel class.

/// initialized in initstate
_localeModel = Provider.of<LocaleModel>(context, listen: false);

access the description in the widget using _localeModel.

localize(_localeModel.translations['description'],[user.location.city, user.location.state, user.location.country]),

And this is how the description widget looks.

And thats how we can localize the entire app,The syntax might look bit ugly but we can always simplfy it. And we can change the language of the app like this

_localeModel.changelocale(Locale('es')); // changing to spanish

And you can see few more additional things done in the source code like storing and fetching the current locale for the next launch using sharedPreference. And thats it we are at the end.

Summing up​

This approach allows you to

• Dynamically edit the translation files.

• Add/ Remove support for a new language. both without making a single line of change in your flutter app.

• No hassle with generating arb files and maintaining static translations Things it lacks: Numbers,Dates and Currencies translation but we can always have custom functions for these or this could also be backend driven within the same translation object. That said we are at the end of this blog post hope you like this approach, And if you have any questions or critiques feel free to drop them below in the comments I would love to discuss. And don't forget to smash the 👏🏼 button until it warns.The more you clap the more it inspires me to bring some great blog posts. And you can always

• play with the source code here

• checkout the demo app here.

Thank you for taking the time to read this long post and keep fluttering 💙.