Setup Internationalization

[shjortConcordium]

Purpose

Setup internationalization, and show of usage. (using terms and condition screen)

Changes

• Setup internationalization using flutter_localizations and intl.
• Replace raw text in terms and conditions screen with localization.
• Use localization in test instead of raw text.

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

[ghost]

Consider add an extension like this

import 'package:flutter/material.dart';
import 'package:flutter_gen/gen_l10n/app_localizations.dart';

extension AppLocalizationsExt on BuildContext {
  AppLocalizations get l10n => AppLocalizations.of(this);
}

Then localized strings can be get by using context.l10n.initializing instead of AppLocalizations.of(context).initializing.

[ghost]

I seems like this file could quite fast get messy if we don’t have some structure.

@TouHouNo or @prinshamlet do you have any good advice or experience on this?

[shjortConcordium]

It's probably good to have some convention in the names for the structure that includes "module names", like using "intro_page__text_name" 🤔
@rh-concordium might also have some insight on this.

[rh-concordium]

Yes, I would suggest grouping related texts keys according to functionality using dot notation. E.g., "onboarding.intro_text", "onboarding.terms_and_conditions", etc. Then you could use additional additional dots if you want to further subgroup your functionality/texts.

I wouldn't use dots for general terms like "Ok", "Continue", etc, though

[shjortConcordium]

I like the dot notation, but it seems impossible with the current setup.

Generating synthetic localizations package failed with 1 error:

Exception: Invalid ARB resource name "terms_and_conditions.before_you_begin" in LocalFile:
'/home/hjort/Projects/concordium-wallet/lib/l10n/app_en.arb'.
Resources names must be valid Dart method names: they have to be camel case, cannot start with a number or
underscore, and cannot contain non-alphanumeric characters.

We can do camelCase with underscore as the separator: onboarding_termsAndConditions? 🤔

[ghost]

Could we use more descriptive names instead of _0 and _1?

[shjortConcordium]

Hmm, I'm not sure there are more descriptive names, it's just one text split into two paragraphs.
I think the right thing is merging them? 🤔
(I've tried doing that)

[rh-concordium]

Nitpicking: Is "cont" a common abreviation for "Continue" at concordium? Otherwise, I would just use the full name as the key for readability

[shjortConcordium]

It is not a common abbreviation.
I did it because both Continue and continue are "bad" keys. Continue is rejected by the generator and continue causes compile issues because it is a keyword.
Maybe there is a better solution though? 🤔

[rh-concordium]

PS: In my old job we were using string xml files, which is why we could get away with dots and we could use whatever keys we liked (and the reason we were using string xml files was that we had a huge language file already 5000+ words that was shared with other native apps)

[rh-concordium]

Yes, I would suggest grouping related texts keys according to functionality using dot notation. E.g., "onboarding.intro_text", "onboarding.terms_and_conditions", etc. Then you could use additional additional dots if you want to further subgroup your functionality/texts.

I wouldn't use dots for general terms like "Ok", "Continue", etc, though

[rh-concordium]

Nitpicking: Is "cont" a common abreviation for "Continue" at concordium? Otherwise, I would just use the full name as the key for readability