CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

Introduction - Purpose & Problem

1. Language selection

2 Rendering the language
How do we go about rendering the screen in that language?
In the previous step, we’ve identified the language in which a view is to be rendered. It is important to note that this language may not only differ for a different user, but also for a different page for the same user. The question now becomes, how do we render the screen in this language? To tackle this question, we explore 2 fundamental concepts:
Views are composed of independent language elements
While this is something we typically take for granted, it becomes especially important in the context of translation. That is, a view is not a single contiguous block of text, nor is it an atomic visualization of information (unlike a screenshot), but rather a carefully organized collection of individual elements such as texts, buttons, etc that each contain language that needs to be translated separately. Crucially, this means that we cannot swap out a page in one language in its entirety for a page in another language in its entirety. Instead, each individual element needs to be swapped out individually so as to only impact the language and not the structural composition of the page itself.
*Views require translation at a large number of call sites
Given that a view is composed of individual elements, this also means that the computation of how to translate such an element such as a button’s text would need to be done separately for each element. This would result in not only a single centralized

3. Translation gaps

Design

Proposed Solution 1. Language selection

2. Rendering the language
Rendering the language
Once we have determined the language in which to render the page, we now need to update the rails view code to actually generate the appropriate HTML in the target language. This is the responsibility of the view. However, currently, the actual content of the HTML is hardcoded in (red) English. For example:

<h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4>

As discussed earlier, “Views are composed of independent language elements” and so we cannot simply swap out the entire page content for a separate page in another language (Why? - See “swap out the entire view” in the alternative approaches section):

<h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4>

Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:

<h2><%=language==’en’ ? ‘Summary Report for assignment’ : ‘Rapport de synthèse pour l'affectation’>: <%= @assignment.name %></h2>
<h4><%=language==’en’ ? ‘Team’ : ‘Équipe’>: <%= @team.name %></h4>

However this is clearly infeasible considering the number of call sites where we have to apply this logic. Thus, in order to maximize how concise the call site is, we can pull out this logic into a common helper function:

<h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4>

I18n - Internationalisation, How are we using I18n in Ruby on Rails 7 3. Translation gaps

Major design patterns and principles used

1. DRY: The i18n ‘t’ function
We observe an extreme case of DRY with the t function of i18n. For some background, the t function of the library takes in a key representing a text and returns the content referred to by that key in the preferred language of the user. It also performs many other functions such as falling back to a backup language if the translation for the preferred language has not been configured for that specific key. Thus since this logic has to be applied at every element of the view, it would behove us to extract this logic into a reusable function which is what the designers of the i18n library have employed

2. Chain of responsibility
@ajulka

3. Open closed principle & Strategy Pattern
As discussed in the “Language selection" design proposal above, if the user has not selected a preferred language, we do not simply default the view to render in the application language (English). Instead, the project requirements state that for course specific screens such as the assignment view, we would need to render the view in the course’s language. While we could implement this code into the application controller that checks the controller being access and accordingly applies overrides on the default language, this violates the open closed principle since we would need to extend this logic any time we introduce a new course specific screen. Instead a better approach is to delegate the decision of selecting the language to the view itself since the view would be most aware of whether the view is course specific or not. We can also preserve the DRYness through mix-ins.

Database Design

Database Modification ==

Test Plan

Test Details Manual Testing Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5

Future Scope

1. Expand to more languages
As part of this project we have targetted Hindi as a second language, however our work makes it easy to extend to other languages as well.

2. Identify and implement the course language override on more course specific screens
As part of this project, we have introduced a generic framework by which any view can provide a preferred language in which it should be rendered, this is required by this project for the course language feature set by the instructor. We have currently made the assignment screen display in the course’s language, however other screens such as the “Your work” screen and so on are also specific to the course could also be rendered in the course language when the user has not provided a preference.

Team

Team Members

Reuben M. V. John [rmjohn2@ncsu.edu]
Renji Joseph Sabu [rsabu@ncsu.edu]
Ashwin Das [adas9@ncsu.edu]
Arnav Julka [ajulka@ncsu.edu]

Mentor

Jialin Cui [jcui9@ncsu.edu]