[Lecture Topic Task] Using diagrams to conceptualize how to implement the Multi-language Support functionality

[cristianMarcial]

Description

A dstate diagram, will be used to show the structure between the modules or event that will be created or modified to enable Multi-language Support.

Objective

In order to modify the application to include the functionality of changing the application language, we need to be clear about the relationship between [...]

• the modules that contain the UI content strings
• the modules that manage these modules (how these modules change according to the interaction with the user)
• the files which have the text to be displayed on the UI content strings
• and the modules that manages these files

[...] in order to have a clear plan about what we need to modify.

And of course, what is described in this diagram is not the current structure of the application, but the one we are looking to create. For example, this diagram could show the implementation of a future module or functionality to be created that refreshes the page when you change the language, and it would show how this relates to the components of the application to carry out its action.

Requirements

The created state diagram shows the structure between the modules and event that enable or will enable the Multi-language Support functionality.

Time Constrains & Deadline

It's preferable that we have this done by the end of the weekend so that we can use this diagram to work with the stipulated app structure on the next week. Deadline: 2024-11-18

Difficulty

5, since it needed knowing how to manage state diagrams

Priority

7, since we need this in our team to have a general understanding on the tasks we are going to do.

Suggested Asignees

@cristianMarcial, @keisanabria

[cristianMarcial]

[cristianMarcial]

Diagram showing the relationship between screen modules with a focus on their relationships with the language module

[cristianMarcial]

Update:

[cristianMarcial]

Description (old)

This diagram shows how the modules relate to each other with the 'language.py' module creating the functionality of being able to change the language displayed in the interface by interacting with the modules that compose it. In both scenarios, an instance is shown in which the module where the button that enables the functionality is visible (which are login and profile), the user can either move to another state where the button is not visible, or can change the language, which will cause the modules in each scenario to reload. The screen modules shown here are Profile, Main Menu and Login; the term othermodules represents other screen modules that are also there but are not relevant to the functionality (e.g. Main Menu is relevant because even though the language change button is invisible in it, it is an input module). The show[module] functions were omitted in the second scenario to avoid redundancy and display issues.

Updated description:

This diagram shows how the modules relate to each other with the 'language.py' module creating the functionality of being able to change the name inside the variable with the name of the language to be displayed in the interface inside the 'language' module, module that fetch the translated UI content strings & and returns them so the screen modules can use them. In both scenarios, an instance is shown where the module where the button that enables the functionality is visible (which are login and profile), the user can either move to another state where the button is not visible, or can change the language, which will cause the modules in each scenario to reload. The screen modules shown here are Profile, Main Menu and Login; the term other_modules represents other screen modules that are also there but are not relevant to the functionality (e.g. Main Menu is relevant because even though the language change button is invisible in it, it is an input module).

The show_[module] functions were omitted in the second scenario to avoid redundancy and display issues.

[cristianMarcial]

@keisanabria thoughts on the description?

[keisanabria]

Hi! I think the diagram and description are on the right track but need to incorporate data management and planned changes more explicitly to fully meet the requirements.

What the Diagram Misses:

• Files Managing Text Strings: The diagram does not explicitly include files or data sources (e.g., configuration files or databases) that store UI content strings, nor does it show how they are linked to the modules.
• Management Modules: While it shows functions (set_language(), reload_page()), it does not detail modules or systems managing these text files or controlling UI updates based on language selection.
• Future Modifications: The description mentions that this state is aspirational but does not explicitly highlight future components or modules that need to be created beyond reloading mechanisms.

Recommendations to Fully Resolve the Issue:

• Add Data Source Connections: Include elements representing files or databases containing UI strings and show their interactions with the set_language() or reload functions.
• Detail Management Logic: Specify modules (or services) that handle language-related actions, such as fetching and applying translated content.
• Highlight Planned Components: Use annotations or labels to indicate which parts of the system are future additions, per the issue's request for planned modifications.