Implement Localization Management

[esmaeil-ahmadipour]

Overview

Feature Description

This feature aims to integrate l10n_flutter into the project, leveraging the Bloc pattern to handle localization state management. The primary objective is to provide a robust and scalable solution for managing app translations, enabling seamless language switching throughout the application.

The implementation will ensure that all text strings in the app are dynamically fetched based on the selected language, allowing for a better user experience. Additionally, this setup will provide a clean structure for developers to easily add new languages or update existing translations in the future.

Click to expand the scenario

Scenario: Testing the Localization Flow

Imagine a developer enables localization in the app and configures two languages: English and French. They start by setting English as the default language and navigate through the app to confirm all text strings display correctly.

Next, ( Currently only enabled for developer and debug mode‍‍ ) they switch the language to French via a dedicated dropdown or settings option. Upon changing the language, all UI elements dynamically update to reflect the selected language. The developer verifies that switching back to English also works seamlessly without restarting the app.

This process ensures that language changes are handled efficiently, maintaining the app's stability and improving the overall user experience.

Design Reference

• Figma Design: Link to Figma Design
  All UI text should match the design's language elements for English and French versions. Please refer to the Figma design for the exact text strings and ensure they are implemented as per the provided layout and styling.

• Responsive Design:
  Localization does not currently impact the app's responsive design. Responsive adjustments can be reviewed and addressed separately if needed in future updates.

• Platform-Specific Implementations:
  Localization should be supported across all platforms, and the language preference should be correctly stored and loaded.

• Data Requirements:
  A JSON or ARB file for each supported language containing the required translations.

[b00f]

It's a good idea to have translation and localization in an application. However, based on our experience with the website (our website was multilingual before), I have some comments to share:

1. Translations easily become outdated and need to be retranslated frequently:
   We addressed this issue on the website by assigning a version number to each original and translated item to ensure consistency. For example:

   # en.yml
   key_1: "[ver: 2] bar"
   
   # xx.yml
   key_1: "[ver: 1] foo"

   Whenever an item in the original file was updated, we increased its version number. This automatically marked all other translations as outdated.

2. Using AI tools makes translation, at least for websites, somewhat unnecessary:
   I believe that for applications, users can also rely on modern AI tools to get translated versions on demand. This is why we decided to remove translations entirely from the new website.

[esmaeil-ahmadipour]

@b00f

Multi-Language Decision in Flutter

Before diving into development, it's essential for Flutter developers to carefully evaluate the need for multi-language and multi-theme support. These decisions directly impact the user experience, scalability, and maintenance costs of the application. Below, three key options for multi-language implementation are outlined:

---

Option 1: Implement Multi-Language Support (Highly Recommended)

Adding multi-language support offers several advantages:

1. Investment Value
   Supporting multiple languages (e.g., Chinese, Arabic) positions your app for global markets, unlocking new revenue opportunities.

2. Cost Efficiency
   Implementing multi-language support with packages like i10n or flutter_localizations is straightforward and involves minimal cost.

3. Ease of Maintenance
   Properly designed localization infrastructure allows for simple, accurate, and error-free text updates.

---

Option 2: Skip Multi-Language Support (Enable User-Driven Translation)

In this approach, the app doesn't natively support multiple languages, leaving users to translate text manually via tools like Google Translate.

• Pros:

  • Reduced development time and cost.
  • Quicker deployment.

• Cons:

  • Requires additional development for enabling text selection and integration with external translation tools.
  • Provides a suboptimal user experience.

• Limitations:
  This approach may not be suitable for commercial or enterprise apps where a polished user experience is crucial.

---

Option 3: Prepare for Future Multi-Language Implementation

If the decision to implement multi-language support is deferred, it’s wise to prepare the codebase for future scalability.

• Proposed Solution:
  Avoid hardcoding text. Instead, manage all text through a centralized class or external files.

• Example:
  Instead of:

  Text("Welcome to the app!")

Use:

Text(AppStrings.welcomeMessage)

This ensures minimal code rewriting when introducing multi-language support later.

Conclusion

1. For apps targeting global markets, multi-language support is strongly recommended.
2. If reducing initial costs is the priority, enabling manual user translation is an option, albeit with drawbacks.
3. If undecided, preparing for future scalability by designing the codebase for extensibility is the best path forward.

[Ja7ad]

Multi-Language Decision in Flutter

Before diving into development, it's essential for Flutter developers to carefully evaluate the need for multi-language and multi-theme support. These decisions directly impact the user experience, scalability, and maintenance costs of the application. Below, three key options for multi-language implementation are outlined:

---

Option 1: Implement Multi-Language Support (Highly Recommended)

Adding multi-language support offers several advantages:

1. Investment Value
   Supporting multiple languages (e.g., Chinese, Arabic) positions your app for global markets, unlocking new revenue opportunities.

2. Cost Efficiency
   Implementing multi-language support with packages like i10n or flutter_localizations is straightforward and involves minimal cost.

3. Ease of Maintenance
   Properly designed localization infrastructure allows for simple, accurate, and error-free text updates.

---

Option 2: Skip Multi-Language Support (Enable User-Driven Translation)

In this approach, the app doesn't natively support multiple languages, leaving users to translate text manually via tools like Google Translate.

• Pros:

  • Reduced development time and cost.
  • Quicker deployment.

• Cons:

  • Requires additional development for enabling text selection and integration with external translation tools.
  • Provides a suboptimal user experience.

• Limitations:
  This approach may not be suitable for commercial or enterprise apps where a polished user experience is crucial.

---

Option 3: Prepare for Future Multi-Language Implementation

If the decision to implement multi-language support is deferred, it’s wise to prepare the codebase for future scalability.

• Proposed Solution:
  Avoid hardcoding text. Instead, manage all text through a centralized class or external files.

• Example:
  Instead of:

  Text("Welcome to the app!")
  ‍‍‍```
  
  Use:
  
  ```dart

Text(AppStrings.welcomeMessage)
‍‍‍```

This ensures minimal code rewriting when introducing multi-language support later.

Conclusion

1. For apps targeting global markets, multi-language support is strongly recommended.
2. If reducing initial costs is the priority, enabling manual user translation is an option, albeit with drawbacks.
3. If undecided, preparing for future scalability by designing the codebase for extensibility is the best path forward.

You can use i18n standard for multiple localization.

[esmaeil-ahmadipour]

Hoang @phoenixit99 : Please follow the Conventional Commits standard for writing commit messages. This helps maintain clear and organized commit histories, which is already practiced in other Pactus repositories.

You can also review the team's contribution guidelines in the CONTRIBUTING file of the Pactus-GUI repository.

Note that this file will be updated over time with the team's latest internal standards.

[esmaeil-ahmadipour]

thanks to @phoenixit99 , I have successfully reorganized the folder structure and updated the ci.yml file. To save data in local storage and read it at startup, a separate issue will be required to handle these tasks.

[b00f]

Please follow the Conventional Commits standard for writing commit messages.

You can use GitHub action to verify and check the commit messages. Look here