Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-30T06:44:58Z

Ajulka:

== Important Links ==
*Git PR - https://github.com/expertiza/expertiza/pull/2151
*Git beta branch - https://github.com/arnavjulka/expertiza/tree/beta
*Overall Video - https://drive.google.com/file/d/1dc9St9J77q-Mb_vRuYBg4vs9Xv0SHm4d/view?usp=sharing
*Testing Video - https://drive.google.com/file/d/1TOatjhe0wzxTpmWDuC_ryVFmtQ-X7FJq/view?usp=sharing

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Every user has an option to set a language preference in the User Profile Information Edit page.

[[File:ProfileEditPage.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the course default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
<ul>
<li>
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
</li>
<li>
The given text is non-trivial to translate to the target language
</li>
</ul>
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the user has set a language preference all pages are displayed in that language.</li>

<li>If the user has not set a language preference and the user is an instructor, all the pages are displayed in English.</li>

<li>If the user has not set a language preference and the user is a student who is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

The below functions are added and called before page rendering to bring in this logic.
<pre>
before_action :set_locale

def set_locale
# Checks whether the user is logged in, else the default locale is used
if logged_in?
# If the current user has set his preferred language, the locale is set according to their preference
if @current_user.locale != "no_pref"
I18n.locale = @current_user.locale
# If the user doesn't have any preference, the locale is taken from the course locale, if the current page is a course specific page or else default locale is used
elsif current_user_role? && current_user_role.student? && ["student_task", "sign_up_sheet", "student_teams", "student_review", "grades", "submitted_content", "participants"].include?(params[:controller])
set_new_locale_for_student
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end

def set_new_locale_for_student
# Gets participant using student from params
if !params[:id].nil? || !params[:student_id].nil?
participant_id = params[:id] || params[:student_id]
participant = AssignmentParticipant.find_by(id: participant_id)
# If id or student_id not correct, revert to locale based on courses.
if participant.nil?
find_locale_from_courses
return
end
# Find assignment from participant and find locale from the assigment
assignment = participant.assignment
if !assignment.course.nil?
new_locale = assignment.course.locale
if !new_locale.nil?
I18n.locale = new_locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
else
find_locale_from_courses
end
end

def find_locale_from_courses
# If the page is a course or assignment page with no specific student id, every course of that student is checked and if
# the language for all these course are same, the page is displayed in that language
courseParticipants = CourseParticipant.where(user_id: current_user.id)
courseParticipantsLocales = courseParticipants.map { |cp| cp.course.locale }
# If no tasks, then possible to have no courses assigned.
if courseParticipantsLocales.uniq.length == 1 #&& !@tasks.empty?
course = courseParticipants.first.course
if course.locale?
I18n.locale = course.locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end
</pre>

<li>If the student user has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Why did we store the default language choices in database instead of in session?'''<br>
We had to decide on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we did was to move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this wasn't much of an issue.

<li>Storing user language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

After considering these points, we finally decided to go store the user preference in the database itself as the project requires us to add a language preference field in user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The user has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>All pages including the course-related and non-course-related pages are displayed in the user preferred language for any user other than student</li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
We add the locale field to the users and courses tables which has the default values 0 and 1, which is no preference and en_US respectively.

The migrations will look as follows:

<pre>
class AddLangLocaleToUsers < ActiveRecord::Migration
def change
add_column :users, :locale, :integer, default: 0
end
end
</pre>

<pre>
class AddLocaleToCourses < ActiveRecord::Migration
def change
add_column :courses, :locale, :integer, default: 1
end
end
</pre>

== Database Modification ==
We add a new integer field to the users table to store the user preferred language. The integer will be hashed to the supported languages. The default value in the table will be 0, which will be no_pref.

<pre>
enum locale: {
no_pref: 0,
en_US: 1,
hi_IN: 2
}
</pre>

We also add a new integer field to the courses table to store the course preferred language. The integer will be hashed to the supported languages. The default value in the table will be 1, which will be en_US.

<pre>
enum locale: {
en_US: 1,
hi_IN: 2
}
</pre>

Hence the updated courses table will look like following:

<pre>
create_table "courses", force: :cascade do |t|
t.string "name", limit: 255
t.integer "instructor_id", limit: 4
t.string "directory_path", limit: 255
t.text "info", limit: 65535
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "private", default: false, null: false
t.integer "institutions_id", limit: 4
t.integer "locale", limit: 4, default: 1
end
</pre>

While the updated users table will look like the following:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false
t.string "crypted_password", limit: 40, default: "", null: false
t.integer "role_id", limit: 4, default: 0, null: false
t.string "password_salt", limit: 255
t.string "fullname", limit: 255
t.string "email", limit: 255
t.integer "parent_id", limit: 4
t.boolean "private_by_default", default: false
t.string "mru_directory_path", limit: 128
t.boolean "email_on_review"
t.boolean "email_on_submission"
t.boolean "email_on_review_of_review"
t.boolean "is_new_user", default: true, null: false
t.integer "master_permission_granted", limit: 1, default: 0
t.string "handle", limit: 255
t.text "digital_certificate", limit: 16777215
t.string "persistence_token", limit: 255
t.string "timezonepref", limit: 255
t.text "public_key", limit: 16777215
t.boolean "copy_of_emails", default: false
t.integer "institution_id", limit: 4
t.boolean "preference_home_flag", default: true
t.integer "locale", limit: 4, default: 0
end
</pre>

The locale field is the last column on both tables:
<pre>
courses:> t.integer "locale", limit: 4, default: 1
</pre>
<pre>
users:> t.integer "locale", limit: 4, default: 0
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to No Preferences.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

===Automated Testing===
Testing Video - https://drive.google.com/file/d/1TOatjhe0wzxTpmWDuC_ryVFmtQ-X7FJq/view?usp=sharing

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 most course specific pages translated according to course language preference when the user has not provided any preference, but we need to identify if we have left out any other course specific page and add those to the list of pages which should take the course language setting into consideration.

== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-30T06:41:02Z

Ajulka: /* Test Plan */

== Important Links ==
*Git PR - https://github.com/expertiza/expertiza/pull/2151
*Git beta branch - https://github.com/arnavjulka/expertiza/tree/beta
*Overall Video - https://drive.google.com/file/d/1dc9St9J77q-Mb_vRuYBg4vs9Xv0SHm4d/view?usp=sharing
*Feature Explanation video -
*Testing Video - https://drive.google.com/file/d/1TOatjhe0wzxTpmWDuC_ryVFmtQ-X7FJq/view?usp=sharing

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Every user has an option to set a language preference in the User Profile Information Edit page.

[[File:ProfileEditPage.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the course default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
<ul>
<li>
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
</li>
<li>
The given text is non-trivial to translate to the target language
</li>
</ul>
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the user has set a language preference all pages are displayed in that language.</li>

<li>If the user has not set a language preference and the user is an instructor, all the pages are displayed in English.</li>

<li>If the user has not set a language preference and the user is a student who is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

The below functions are added and called before page rendering to bring in this logic.
<pre>
before_action :set_locale

def set_locale
# Checks whether the user is logged in, else the default locale is used
if logged_in?
# If the current user has set his preferred language, the locale is set according to their preference
if @current_user.locale != "no_pref"
I18n.locale = @current_user.locale
# If the user doesn't have any preference, the locale is taken from the course locale, if the current page is a course specific page or else default locale is used
elsif current_user_role? && current_user_role.student? && ["student_task", "sign_up_sheet", "student_teams", "student_review", "grades", "submitted_content", "participants"].include?(params[:controller])
set_new_locale_for_student
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end

def set_new_locale_for_student
# Gets participant using student from params
if !params[:id].nil? || !params[:student_id].nil?
participant_id = params[:id] || params[:student_id]
participant = AssignmentParticipant.find_by(id: participant_id)
# If id or student_id not correct, revert to locale based on courses.
if participant.nil?
find_locale_from_courses
return
end
# Find assignment from participant and find locale from the assigment
assignment = participant.assignment
if !assignment.course.nil?
new_locale = assignment.course.locale
if !new_locale.nil?
I18n.locale = new_locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
else
find_locale_from_courses
end
end

def find_locale_from_courses
# If the page is a course or assignment page with no specific student id, every course of that student is checked and if
# the language for all these course are same, the page is displayed in that language
courseParticipants = CourseParticipant.where(user_id: current_user.id)
courseParticipantsLocales = courseParticipants.map { |cp| cp.course.locale }
# If no tasks, then possible to have no courses assigned.
if courseParticipantsLocales.uniq.length == 1 #&& !@tasks.empty?
course = courseParticipants.first.course
if course.locale?
I18n.locale = course.locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end
</pre>

<li>If the student user has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Why did we store the default language choices in database instead of in session?'''<br>
We had to decide on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we did was to move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this wasn't much of an issue.

<li>Storing user language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

After considering these points, we finally decided to go store the user preference in the database itself as the project requires us to add a language preference field in user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The user has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>All pages including the course-related and non-course-related pages are displayed in the user preferred language for any user other than student</li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
We add the locale field to the users and courses tables which has the default values 0 and 1, which is no preference and en_US respectively.

The migrations will look as follows:

<pre>
class AddLangLocaleToUsers < ActiveRecord::Migration
def change
add_column :users, :locale, :integer, default: 0
end
end
</pre>

<pre>
class AddLocaleToCourses < ActiveRecord::Migration
def change
add_column :courses, :locale, :integer, default: 1
end
end
</pre>

== Database Modification ==
We add a new integer field to the users table to store the user preferred language. The integer will be hashed to the supported languages. The default value in the table will be 0, which will be no_pref.

<pre>
enum locale: {
no_pref: 0,
en_US: 1,
hi_IN: 2
}
</pre>

We also add a new integer field to the courses table to store the course preferred language. The integer will be hashed to the supported languages. The default value in the table will be 1, which will be en_US.

<pre>
enum locale: {
en_US: 1,
hi_IN: 2
}
</pre>

Hence the updated courses table will look like following:

<pre>
create_table "courses", force: :cascade do |t|
t.string "name", limit: 255
t.integer "instructor_id", limit: 4
t.string "directory_path", limit: 255
t.text "info", limit: 65535
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "private", default: false, null: false
t.integer "institutions_id", limit: 4
t.integer "locale", limit: 4, default: 1
end
</pre>

While the updated users table will look like the following:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false
t.string "crypted_password", limit: 40, default: "", null: false
t.integer "role_id", limit: 4, default: 0, null: false
t.string "password_salt", limit: 255
t.string "fullname", limit: 255
t.string "email", limit: 255
t.integer "parent_id", limit: 4
t.boolean "private_by_default", default: false
t.string "mru_directory_path", limit: 128
t.boolean "email_on_review"
t.boolean "email_on_submission"
t.boolean "email_on_review_of_review"
t.boolean "is_new_user", default: true, null: false
t.integer "master_permission_granted", limit: 1, default: 0
t.string "handle", limit: 255
t.text "digital_certificate", limit: 16777215
t.string "persistence_token", limit: 255
t.string "timezonepref", limit: 255
t.text "public_key", limit: 16777215
t.boolean "copy_of_emails", default: false
t.integer "institution_id", limit: 4
t.boolean "preference_home_flag", default: true
t.integer "locale", limit: 4, default: 0
end
</pre>

The locale field is the last column on both tables:
<pre>
courses:> t.integer "locale", limit: 4, default: 1
</pre>
<pre>
users:> t.integer "locale", limit: 4, default: 0
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to No Preferences.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

===Automated Testing===
Testing Video - https://drive.google.com/file/d/1TOatjhe0wzxTpmWDuC_ryVFmtQ-X7FJq/view?usp=sharing

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 most course specific pages translated according to course language preference when the user has not provided any preference, but we need to identify if we have left out any other course specific page and add those to the list of pages which should take the course language setting into consideration.

== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-30T06:39:23Z

Ajulka:

== Important Links ==
*Git PR - https://github.com/expertiza/expertiza/pull/2151
*Git beta branch - https://github.com/arnavjulka/expertiza/tree/beta
*Overall Video - https://drive.google.com/file/d/1dc9St9J77q-Mb_vRuYBg4vs9Xv0SHm4d/view?usp=sharing
*Feature Explanation video -
*Testing Video - https://drive.google.com/file/d/1TOatjhe0wzxTpmWDuC_ryVFmtQ-X7FJq/view?usp=sharing

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Every user has an option to set a language preference in the User Profile Information Edit page.

[[File:ProfileEditPage.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the course default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
<ul>
<li>
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
</li>
<li>
The given text is non-trivial to translate to the target language
</li>
</ul>
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the user has set a language preference all pages are displayed in that language.</li>

<li>If the user has not set a language preference and the user is an instructor, all the pages are displayed in English.</li>

<li>If the user has not set a language preference and the user is a student who is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

The below functions are added and called before page rendering to bring in this logic.
<pre>
before_action :set_locale

def set_locale
# Checks whether the user is logged in, else the default locale is used
if logged_in?
# If the current user has set his preferred language, the locale is set according to their preference
if @current_user.locale != "no_pref"
I18n.locale = @current_user.locale
# If the user doesn't have any preference, the locale is taken from the course locale, if the current page is a course specific page or else default locale is used
elsif current_user_role? && current_user_role.student? && ["student_task", "sign_up_sheet", "student_teams", "student_review", "grades", "submitted_content", "participants"].include?(params[:controller])
set_new_locale_for_student
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end

def set_new_locale_for_student
# Gets participant using student from params
if !params[:id].nil? || !params[:student_id].nil?
participant_id = params[:id] || params[:student_id]
participant = AssignmentParticipant.find_by(id: participant_id)
# If id or student_id not correct, revert to locale based on courses.
if participant.nil?
find_locale_from_courses
return
end
# Find assignment from participant and find locale from the assigment
assignment = participant.assignment
if !assignment.course.nil?
new_locale = assignment.course.locale
if !new_locale.nil?
I18n.locale = new_locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
else
find_locale_from_courses
end
end

def find_locale_from_courses
# If the page is a course or assignment page with no specific student id, every course of that student is checked and if
# the language for all these course are same, the page is displayed in that language
courseParticipants = CourseParticipant.where(user_id: current_user.id)
courseParticipantsLocales = courseParticipants.map { |cp| cp.course.locale }
# If no tasks, then possible to have no courses assigned.
if courseParticipantsLocales.uniq.length == 1 #&& !@tasks.empty?
course = courseParticipants.first.course
if course.locale?
I18n.locale = course.locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end
</pre>

<li>If the student user has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Why did we store the default language choices in database instead of in session?'''<br>
We had to decide on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we did was to move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this wasn't much of an issue.

<li>Storing user language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

After considering these points, we finally decided to go store the user preference in the database itself as the project requires us to add a language preference field in user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The user has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>All pages including the course-related and non-course-related pages are displayed in the user preferred language for any user other than student</li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
We add the locale field to the users and courses tables which has the default values 0 and 1, which is no preference and en_US respectively.

The migrations will look as follows:

<pre>
class AddLangLocaleToUsers < ActiveRecord::Migration
def change
add_column :users, :locale, :integer, default: 0
end
end
</pre>

<pre>
class AddLocaleToCourses < ActiveRecord::Migration
def change
add_column :courses, :locale, :integer, default: 1
end
end
</pre>

== Database Modification ==
We add a new integer field to the users table to store the user preferred language. The integer will be hashed to the supported languages. The default value in the table will be 0, which will be no_pref.

<pre>
enum locale: {
no_pref: 0,
en_US: 1,
hi_IN: 2
}
</pre>

We also add a new integer field to the courses table to store the course preferred language. The integer will be hashed to the supported languages. The default value in the table will be 1, which will be en_US.

<pre>
enum locale: {
en_US: 1,
hi_IN: 2
}
</pre>

Hence the updated courses table will look like following:

<pre>
create_table "courses", force: :cascade do |t|
t.string "name", limit: 255
t.integer "instructor_id", limit: 4
t.string "directory_path", limit: 255
t.text "info", limit: 65535
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "private", default: false, null: false
t.integer "institutions_id", limit: 4
t.integer "locale", limit: 4, default: 1
end
</pre>

While the updated users table will look like the following:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false
t.string "crypted_password", limit: 40, default: "", null: false
t.integer "role_id", limit: 4, default: 0, null: false
t.string "password_salt", limit: 255
t.string "fullname", limit: 255
t.string "email", limit: 255
t.integer "parent_id", limit: 4
t.boolean "private_by_default", default: false
t.string "mru_directory_path", limit: 128
t.boolean "email_on_review"
t.boolean "email_on_submission"
t.boolean "email_on_review_of_review"
t.boolean "is_new_user", default: true, null: false
t.integer "master_permission_granted", limit: 1, default: 0
t.string "handle", limit: 255
t.text "digital_certificate", limit: 16777215
t.string "persistence_token", limit: 255
t.string "timezonepref", limit: 255
t.text "public_key", limit: 16777215
t.boolean "copy_of_emails", default: false
t.integer "institution_id", limit: 4
t.boolean "preference_home_flag", default: true
t.integer "locale", limit: 4, default: 0
end
</pre>

The locale field is the last column on both tables:
<pre>
courses:> t.integer "locale", limit: 4, default: 1
</pre>
<pre>
users:> t.integer "locale", limit: 4, default: 0
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to No Preferences.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 most course specific pages translated according to course language preference when the user has not provided any preference, but we need to identify if we have left out any other course specific page and add those to the list of pages which should take the course language setting into consideration.

== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-30T06:37:24Z

Ajulka:

== Important Links ==
*Git PR - https://github.com/expertiza/expertiza/pull/2151
*Git beta branch - https://github.com/arnavjulka/expertiza/tree/beta
*Overall Video - https://drive.google.com/drive/folders/1PGmiJibMtOhjLh6heGUIkq9r0LSDmG6F
*Feature Explanation video -
*Testing Video - https://drive.google.com/drive/folders/1PGmiJibMtOhjLh6heGUIkq9r0LSDmG6F

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Every user has an option to set a language preference in the User Profile Information Edit page.

[[File:ProfileEditPage.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the course default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
<ul>
<li>
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
</li>
<li>
The given text is non-trivial to translate to the target language
</li>
</ul>
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the user has set a language preference all pages are displayed in that language.</li>

<li>If the user has not set a language preference and the user is an instructor, all the pages are displayed in English.</li>

<li>If the user has not set a language preference and the user is a student who is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

The below functions are added and called before page rendering to bring in this logic.
<pre>
before_action :set_locale

def set_locale
# Checks whether the user is logged in, else the default locale is used
if logged_in?
# If the current user has set his preferred language, the locale is set according to their preference
if @current_user.locale != "no_pref"
I18n.locale = @current_user.locale
# If the user doesn't have any preference, the locale is taken from the course locale, if the current page is a course specific page or else default locale is used
elsif current_user_role? && current_user_role.student? && ["student_task", "sign_up_sheet", "student_teams", "student_review", "grades", "submitted_content", "participants"].include?(params[:controller])
set_new_locale_for_student
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end

def set_new_locale_for_student
# Gets participant using student from params
if !params[:id].nil? || !params[:student_id].nil?
participant_id = params[:id] || params[:student_id]
participant = AssignmentParticipant.find_by(id: participant_id)
# If id or student_id not correct, revert to locale based on courses.
if participant.nil?
find_locale_from_courses
return
end
# Find assignment from participant and find locale from the assigment
assignment = participant.assignment
if !assignment.course.nil?
new_locale = assignment.course.locale
if !new_locale.nil?
I18n.locale = new_locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
else
find_locale_from_courses
end
end

def find_locale_from_courses
# If the page is a course or assignment page with no specific student id, every course of that student is checked and if
# the language for all these course are same, the page is displayed in that language
courseParticipants = CourseParticipant.where(user_id: current_user.id)
courseParticipantsLocales = courseParticipants.map { |cp| cp.course.locale }
# If no tasks, then possible to have no courses assigned.
if courseParticipantsLocales.uniq.length == 1 #&& !@tasks.empty?
course = courseParticipants.first.course
if course.locale?
I18n.locale = course.locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end
</pre>

<li>If the student user has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Why did we store the default language choices in database instead of in session?'''<br>
We had to decide on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we did was to move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this wasn't much of an issue.

<li>Storing user language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

After considering these points, we finally decided to go store the user preference in the database itself as the project requires us to add a language preference field in user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The user has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>All pages including the course-related and non-course-related pages are displayed in the user preferred language for any user other than student</li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
We add the locale field to the users and courses tables which has the default values 0 and 1, which is no preference and en_US respectively.

The migrations will look as follows:

<pre>
class AddLangLocaleToUsers < ActiveRecord::Migration
def change
add_column :users, :locale, :integer, default: 0
end
end
</pre>

<pre>
class AddLocaleToCourses < ActiveRecord::Migration
def change
add_column :courses, :locale, :integer, default: 1
end
end
</pre>

== Database Modification ==
We add a new integer field to the users table to store the user preferred language. The integer will be hashed to the supported languages. The default value in the table will be 0, which will be no_pref.

<pre>
enum locale: {
no_pref: 0,
en_US: 1,
hi_IN: 2
}
</pre>

We also add a new integer field to the courses table to store the course preferred language. The integer will be hashed to the supported languages. The default value in the table will be 1, which will be en_US.

<pre>
enum locale: {
en_US: 1,
hi_IN: 2
}
</pre>

Hence the updated courses table will look like following:

<pre>
create_table "courses", force: :cascade do |t|
t.string "name", limit: 255
t.integer "instructor_id", limit: 4
t.string "directory_path", limit: 255
t.text "info", limit: 65535
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "private", default: false, null: false
t.integer "institutions_id", limit: 4
t.integer "locale", limit: 4, default: 1
end
</pre>

While the updated users table will look like the following:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false
t.string "crypted_password", limit: 40, default: "", null: false
t.integer "role_id", limit: 4, default: 0, null: false
t.string "password_salt", limit: 255
t.string "fullname", limit: 255
t.string "email", limit: 255
t.integer "parent_id", limit: 4
t.boolean "private_by_default", default: false
t.string "mru_directory_path", limit: 128
t.boolean "email_on_review"
t.boolean "email_on_submission"
t.boolean "email_on_review_of_review"
t.boolean "is_new_user", default: true, null: false
t.integer "master_permission_granted", limit: 1, default: 0
t.string "handle", limit: 255
t.text "digital_certificate", limit: 16777215
t.string "persistence_token", limit: 255
t.string "timezonepref", limit: 255
t.text "public_key", limit: 16777215
t.boolean "copy_of_emails", default: false
t.integer "institution_id", limit: 4
t.boolean "preference_home_flag", default: true
t.integer "locale", limit: 4, default: 0
end
</pre>

The locale field is the last column on both tables:
<pre>
courses:> t.integer "locale", limit: 4, default: 1
</pre>
<pre>
users:> t.integer "locale", limit: 4, default: 0
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to No Preferences.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 most course specific pages translated according to course language preference when the user has not provided any preference, but we need to identify if we have left out any other course specific page and add those to the list of pages which should take the course language setting into consideration.

== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-30T06:36:04Z

Ajulka:

== Important Links ==
*Git PR - https://github.com/expertiza/expertiza/pull/2151
*Git beta branch - https://github.com/arnavjulka/expertiza/tree/beta

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Every user has an option to set a language preference in the User Profile Information Edit page.

[[File:ProfileEditPage.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the course default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
<ul>
<li>
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
</li>
<li>
The given text is non-trivial to translate to the target language
</li>
</ul>
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the user has set a language preference all pages are displayed in that language.</li>

<li>If the user has not set a language preference and the user is an instructor, all the pages are displayed in English.</li>

<li>If the user has not set a language preference and the user is a student who is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

The below functions are added and called before page rendering to bring in this logic.
<pre>
before_action :set_locale

def set_locale
# Checks whether the user is logged in, else the default locale is used
if logged_in?
# If the current user has set his preferred language, the locale is set according to their preference
if @current_user.locale != "no_pref"
I18n.locale = @current_user.locale
# If the user doesn't have any preference, the locale is taken from the course locale, if the current page is a course specific page or else default locale is used
elsif current_user_role? && current_user_role.student? && ["student_task", "sign_up_sheet", "student_teams", "student_review", "grades", "submitted_content", "participants"].include?(params[:controller])
set_new_locale_for_student
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end

def set_new_locale_for_student
# Gets participant using student from params
if !params[:id].nil? || !params[:student_id].nil?
participant_id = params[:id] || params[:student_id]
participant = AssignmentParticipant.find_by(id: participant_id)
# If id or student_id not correct, revert to locale based on courses.
if participant.nil?
find_locale_from_courses
return
end
# Find assignment from participant and find locale from the assigment
assignment = participant.assignment
if !assignment.course.nil?
new_locale = assignment.course.locale
if !new_locale.nil?
I18n.locale = new_locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
else
find_locale_from_courses
end
end

def find_locale_from_courses
# If the page is a course or assignment page with no specific student id, every course of that student is checked and if
# the language for all these course are same, the page is displayed in that language
courseParticipants = CourseParticipant.where(user_id: current_user.id)
courseParticipantsLocales = courseParticipants.map { |cp| cp.course.locale }
# If no tasks, then possible to have no courses assigned.
if courseParticipantsLocales.uniq.length == 1 #&& !@tasks.empty?
course = courseParticipants.first.course
if course.locale?
I18n.locale = course.locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end
</pre>

<li>If the student user has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Why did we store the default language choices in database instead of in session?'''<br>
We had to decide on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we did was to move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this wasn't much of an issue.

<li>Storing user language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

After considering these points, we finally decided to go store the user preference in the database itself as the project requires us to add a language preference field in user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The user has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>All pages including the course-related and non-course-related pages are displayed in the user preferred language for any user other than student</li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
We add the locale field to the users and courses tables which has the default values 0 and 1, which is no preference and en_US respectively.

The migrations will look as follows:

<pre>
class AddLangLocaleToUsers < ActiveRecord::Migration
def change
add_column :users, :locale, :integer, default: 0
end
end
</pre>

<pre>
class AddLocaleToCourses < ActiveRecord::Migration
def change
add_column :courses, :locale, :integer, default: 1
end
end
</pre>

== Database Modification ==
We add a new integer field to the users table to store the user preferred language. The integer will be hashed to the supported languages. The default value in the table will be 0, which will be no_pref.

<pre>
enum locale: {
no_pref: 0,
en_US: 1,
hi_IN: 2
}
</pre>

We also add a new integer field to the courses table to store the course preferred language. The integer will be hashed to the supported languages. The default value in the table will be 1, which will be en_US.

<pre>
enum locale: {
en_US: 1,
hi_IN: 2
}
</pre>

Hence the updated courses table will look like following:

<pre>
create_table "courses", force: :cascade do |t|
t.string "name", limit: 255
t.integer "instructor_id", limit: 4
t.string "directory_path", limit: 255
t.text "info", limit: 65535
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "private", default: false, null: false
t.integer "institutions_id", limit: 4
t.integer "locale", limit: 4, default: 1
end
</pre>

While the updated users table will look like the following:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false
t.string "crypted_password", limit: 40, default: "", null: false
t.integer "role_id", limit: 4, default: 0, null: false
t.string "password_salt", limit: 255
t.string "fullname", limit: 255
t.string "email", limit: 255
t.integer "parent_id", limit: 4
t.boolean "private_by_default", default: false
t.string "mru_directory_path", limit: 128
t.boolean "email_on_review"
t.boolean "email_on_submission"
t.boolean "email_on_review_of_review"
t.boolean "is_new_user", default: true, null: false
t.integer "master_permission_granted", limit: 1, default: 0
t.string "handle", limit: 255
t.text "digital_certificate", limit: 16777215
t.string "persistence_token", limit: 255
t.string "timezonepref", limit: 255
t.text "public_key", limit: 16777215
t.boolean "copy_of_emails", default: false
t.integer "institution_id", limit: 4
t.boolean "preference_home_flag", default: true
t.integer "locale", limit: 4, default: 0
end
</pre>

The locale field is the last column on both tables:
<pre>
courses:> t.integer "locale", limit: 4, default: 1
</pre>
<pre>
users:> t.integer "locale", limit: 4, default: 0
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to No Preferences.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 most course specific pages translated according to course language preference when the user has not provided any preference, but we need to identify if we have left out any other course specific page and add those to the list of pages which should take the course language setting into consideration.

== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-30T06:35:40Z

Ajulka:

== Important Links ==
Git PR - https://github.com/expertiza/expertiza/pull/2151
Git beta branch - https://github.com/arnavjulka/expertiza/tree/beta

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Every user has an option to set a language preference in the User Profile Information Edit page.

[[File:ProfileEditPage.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the course default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
<ul>
<li>
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
</li>
<li>
The given text is non-trivial to translate to the target language
</li>
</ul>
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the user has set a language preference all pages are displayed in that language.</li>

<li>If the user has not set a language preference and the user is an instructor, all the pages are displayed in English.</li>

<li>If the user has not set a language preference and the user is a student who is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

The below functions are added and called before page rendering to bring in this logic.
<pre>
before_action :set_locale

def set_locale
# Checks whether the user is logged in, else the default locale is used
if logged_in?
# If the current user has set his preferred language, the locale is set according to their preference
if @current_user.locale != "no_pref"
I18n.locale = @current_user.locale
# If the user doesn't have any preference, the locale is taken from the course locale, if the current page is a course specific page or else default locale is used
elsif current_user_role? && current_user_role.student? && ["student_task", "sign_up_sheet", "student_teams", "student_review", "grades", "submitted_content", "participants"].include?(params[:controller])
set_new_locale_for_student
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end

def set_new_locale_for_student
# Gets participant using student from params
if !params[:id].nil? || !params[:student_id].nil?
participant_id = params[:id] || params[:student_id]
participant = AssignmentParticipant.find_by(id: participant_id)
# If id or student_id not correct, revert to locale based on courses.
if participant.nil?
find_locale_from_courses
return
end
# Find assignment from participant and find locale from the assigment
assignment = participant.assignment
if !assignment.course.nil?
new_locale = assignment.course.locale
if !new_locale.nil?
I18n.locale = new_locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
else
find_locale_from_courses
end
end

def find_locale_from_courses
# If the page is a course or assignment page with no specific student id, every course of that student is checked and if
# the language for all these course are same, the page is displayed in that language
courseParticipants = CourseParticipant.where(user_id: current_user.id)
courseParticipantsLocales = courseParticipants.map { |cp| cp.course.locale }
# If no tasks, then possible to have no courses assigned.
if courseParticipantsLocales.uniq.length == 1 #&& !@tasks.empty?
course = courseParticipants.first.course
if course.locale?
I18n.locale = course.locale
else
I18n.locale = I18n.default_locale
end
else
I18n.locale = I18n.default_locale
end
end
</pre>

<li>If the student user has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Why did we store the default language choices in database instead of in session?'''<br>
We had to decide on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we did was to move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this wasn't much of an issue.

<li>Storing user language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

After considering these points, we finally decided to go store the user preference in the database itself as the project requires us to add a language preference field in user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The user has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>All pages including the course-related and non-course-related pages are displayed in the user preferred language for any user other than student</li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
We add the locale field to the users and courses tables which has the default values 0 and 1, which is no preference and en_US respectively.

The migrations will look as follows:

<pre>
class AddLangLocaleToUsers < ActiveRecord::Migration
def change
add_column :users, :locale, :integer, default: 0
end
end
</pre>

<pre>
class AddLocaleToCourses < ActiveRecord::Migration
def change
add_column :courses, :locale, :integer, default: 1
end
end
</pre>

== Database Modification ==
We add a new integer field to the users table to store the user preferred language. The integer will be hashed to the supported languages. The default value in the table will be 0, which will be no_pref.

<pre>
enum locale: {
no_pref: 0,
en_US: 1,
hi_IN: 2
}
</pre>

We also add a new integer field to the courses table to store the course preferred language. The integer will be hashed to the supported languages. The default value in the table will be 1, which will be en_US.

<pre>
enum locale: {
en_US: 1,
hi_IN: 2
}
</pre>

Hence the updated courses table will look like following:

<pre>
create_table "courses", force: :cascade do |t|
t.string "name", limit: 255
t.integer "instructor_id", limit: 4
t.string "directory_path", limit: 255
t.text "info", limit: 65535
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "private", default: false, null: false
t.integer "institutions_id", limit: 4
t.integer "locale", limit: 4, default: 1
end
</pre>

While the updated users table will look like the following:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false
t.string "crypted_password", limit: 40, default: "", null: false
t.integer "role_id", limit: 4, default: 0, null: false
t.string "password_salt", limit: 255
t.string "fullname", limit: 255
t.string "email", limit: 255
t.integer "parent_id", limit: 4
t.boolean "private_by_default", default: false
t.string "mru_directory_path", limit: 128
t.boolean "email_on_review"
t.boolean "email_on_submission"
t.boolean "email_on_review_of_review"
t.boolean "is_new_user", default: true, null: false
t.integer "master_permission_granted", limit: 1, default: 0
t.string "handle", limit: 255
t.text "digital_certificate", limit: 16777215
t.string "persistence_token", limit: 255
t.string "timezonepref", limit: 255
t.text "public_key", limit: 16777215
t.boolean "copy_of_emails", default: false
t.integer "institution_id", limit: 4
t.boolean "preference_home_flag", default: true
t.integer "locale", limit: 4, default: 0
end
</pre>

The locale field is the last column on both tables:
<pre>
courses:> t.integer "locale", limit: 4, default: 1
</pre>
<pre>
users:> t.integer "locale", limit: 4, default: 0
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to No Preferences.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “User Profile Information” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “User Profile Information” page and change “Preferred Language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 most course specific pages translated according to course language preference when the user has not provided any preference, but we need to identify if we have left out any other course specific page and add those to the list of pages which should take the course language setting into consideration.

== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-04T00:51:24Z

Ajulka: /* Alternate approaches */

== Introduction - Purpose & Problem ==

Currently, all Expertiza screens can only be viewed in English. Many Expertiza users are from other countries. This is a problem since this limits the accessibility of Expertiza. An important step in solving this problem is by making Expertiza available in more languages, which is a form of internationalization.
W3C defines [https://www.w3.org/International/questions/qa-i18n internationalization] as “''the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.''”

[[File:country_pie.png|none|500px|]]<br>
Survey of home country of Expertiza users for a given course<br>

'''Scope:''' The scope of this project is limited however only to static strings. i.e. user-generated content will not be automatically translated to other languages.

'''Breaking down internationalization into 3 sequential subproblems:'''<br>
[[File:Twophase2.jpg|none|700px]]<br>
'''1. Language selection'''<br>
Internationalization is done for pages viewed by students only. Any user other than students views all pages in English. The student has the option to set a language preference.

LOFI UI sketch

[[File:language1inter.png]]<br>
There is also an option where the instructor can choose a default language for a course.

[[File:language2inter.png]]

Thus, the language not only varies from user to user but also across screens for the same user. Thus we need to recompute the language in which the page is to be rendered. If the student has given a language preference, then the choice is given weightage over the default language chosen by the instructor.

'''2. Rendering the language'''<br>
'''How do we go about rendering the screen in that language?''' <br>
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?<br>
To tackle this question, we explore 2 fundamental concepts:<br>
'''2.1 Views are composed of independent language elements'''<br>
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.
<br>
'''2.2 Views require translation at a large number of call sites'''<br>
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'''

What if the translation for the target language is not available?
Even translation for a language like Hindi may be available in general, the translation for a given text may not be available Hindi. This may be due to a variety of reasons:
The specific text may have been accidentally missed out (remember the translation is not being done at runtime through an API, but rather curated by the developer)
The given text is non-trivial to translate to the target language
Our design would thus need to accommodate this by seamlessly falling back on another language whose translation is available.

== Scope ==
The scope of this project is limited however only to static strings. I.e. user-generated content will not be automatically translated to other languages.

== Design ==
'''Proposed Solution''' <br>
We explore and solve each of the three problems above in isolation:

'''''1. Language selection'''''<br>
The language in which the page is rendered depends on a set of conditions.

<li>If the student has set a language preference, it overrides the default language setting saved by the instructor, and all pages are displayed in the language preferred by the student.</li>

<li>If the student has not set a language preference and is on a page that is specific to a course for which the instructor has added a default language, the page is displayed in the course’s default language.</li>

<li>If the student has not set a language preference and is not on a course-specific page, then the page is displayed in English.
If a language preference is obtained by following the above conditions but some keys in the page don't have a translation for the language, the English translation for that key is returned as a fallback.</li>

'''''2. Rendering the language'''''<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale). <br>
[[File:i18n.png]]<br>
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
Doing it ourselves felt like a great option. But i18n not just selects a language string at runtime for us it does a lot more under the hood which makes our lives easier. For example, it manages locale over the session for us, even if we change the urls and shift tabs and other stuff it manages our locale. <br>
Also there is a great principle that says - “ If it isn’t broken, Don’t fix it”. The library manages the registering of different language yml files, points to the right right text at runtime, manages session locale and a lot more. So we want to explore this library instead of reimplementing the same thing again.<br>

'''3, Do we store the language preference, in the session or in the database?'''<br>
We are still deciding on whether to keep the student’s language preference in the database or in the session. We have thought about both approaches and below listed are the advantages and disadvantages.

In the work done by the previous team, they added a dropdown in the navbar where a student can choose the preferred language. One of the changes that we intend to do is move this field to the user profile page. The earlier team used session storage to store the preferred language. This session resets on every logout, but since the preferred language can easily be set from any page this won’t be much of an issue.

<li>Storing language preference in database.</li>

If we are moving the language preference field to the user profile page, it will create some user experience issues if the preference is stored in session. The student will have to visit the user profile page every time they log in. To avoid this scenario, it’s better to keep the language preference in the database, so that the preference stays saved across sessions.
The disadvantage of moving the language preference to the database is that it brings forth a schema change and this always requires a very careful going through to ensure that nothing else is affected.

<li>Storing language preference in session storage.</li>

The main advantage of storing the language preference in session storage is that no schema change is involved. This decreases the chance of other features being affected. The main disadvantage is that the student will have to go to the user profile page every time they log in to set the preference, causing a user experience issue. Keep in mind that we’re moving the field away from the navbar to a user profile page.

== Use Case Diagram ==
<li>An instructor can add a default language to any course. English is the default choice.</li>

<li>The student has an option to change their preferred language at any time. They have the option to do so in their profile page. </li>

<li>Every non-course-related page is displayed in the student’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

<li>Every course-related page is displayed in the student’s preferred language. If the student doesn’t have a preferred language, the course is displayed in the course’s preferred language. Keys for which a translation is not found are displayed in the default language that is English.</li>

[[File:usecasediagram.png|2000px|865px]]

== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
[[File:Chainofresp.png]]<br>

The I18n library gives us an option to have many fall back options. When the required text for a given language is not found, we then move on to find the text for the next language in the chain and so on until we find it. And in the end we will put english as default language. So if the key value pair for the text is not found in none of the yml files then the text will be fetched from the English language yml file.
<br>

'''3. Open closed principle & Strategy Pattern'''<br>
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 ==
Currently, we are debating between keeping the language preference in the session or in the database. If we are going with the latter, we have to add a column in the users table.

The migration will look as follows:

<pre>rails generate migration add_language_preference_to_users language_preference:string</pre>

<pre>
class AddLanguagePreferenceToUsers < ActiveRecord::Migration[5.0]
def change
add_column :users, :language_preference, :string
end
end
</pre>

== Database Modification ==
The only need to update the users table if we are keeping the language preference in the DB.
The current schema of the “users” table is :

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false

t.string "crypted_password", limit: 40, default: "", null: false

t.integer "role_id", limit: 4, default: 0, null: false

t.string "password_salt", limit: 255

t.string "fullname", limit: 255

t.string "email", limit: 255

t.integer "parent_id", limit: 4

t.boolean "private_by_default", default: false

t.string "mru_directory_path", limit: 128

t.boolean "email_on_review"

t.boolean "email_on_submission"

t.boolean "email_on_review_of_review"

t.boolean "is_new_user", default: true, null: false

t.integer "master_permission_granted", limit: 1, default: 0

t.string "handle", limit: 255

t.text "digital_certificate", limit: 16777215

t.string "persistence_token", limit: 255

t.string "timezonepref", limit: 255

t.text "public_key", limit: 16777215

t.boolean "copy_of_emails", default: false

t.integer "institution_id", limit: 4

t.boolean "preference_home_flag", default: true

end
</pre>

Which will change to:

<pre>
create_table "users", force: :cascade do |t|
t.string "name", limit: 255, default: "", null: false

t.string "crypted_password", limit: 40, default: "", null: false

t.integer "role_id", limit: 4, default: 0, null: false

t.string "password_salt", limit: 255

t.string "fullname", limit: 255

t.string "email", limit: 255

t.integer "parent_id", limit: 4

t.boolean "private_by_default", default: false

t.string "mru_directory_path", limit: 128

t.boolean "email_on_review"

t.boolean "email_on_submission"

t.boolean "email_on_review_of_review"

t.boolean "is_new_user", default: true, null: false

t.integer "master_permission_granted", limit: 1, default: 0

t.string "handle", limit: 255

t.text "digital_certificate", limit: 16777215

t.string "persistence_token", limit: 255

t.string "timezonepref", limit: 255

t.text "public_key", limit: 16777215

t.boolean "copy_of_emails", default: false

t.integer "institution_id", limit: 4

t.boolean "preference_home_flag", default: true

t.string “language_preference”, limit: 255

end
</pre>

== Test Plan ==

===Manual Testing===

Through manual testing, we aim to identify if all the features of the application are working as intended when the language conversion occurs.

<b>Scenario 1</b>

1. Log in to Expertiza as a student.

2. Go to the “user profile” page and change “preferred language” to Hindi.

3. Check to see if the English strings on the profile page are translated to Hindi.

4. Check if a page for which Hindi translation keys are added has its English static strings translated to Hindi.

<b>Scenario 2</b>

1. Log in to Expertiza as a student.

2. Go to the “user profile” page and change “preferred language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “user profile” translates only if the student has a preference.

4. Go to an assignment page for which Hindi translation keys are added, which is under a course with the default language set to Hindi, and check whether the English strings are translated to Hindi.

<b>Scenario 3</b>

1. Log in to Expertiza as a student.

2. Go to the “user profile” page and change “preferred language” to Nil.

3. Check to see if the English strings on the page are unchanged, as the “user profile” translates only if the student has a preference.

4. Go to a non-course-specific page and verify that the page is displayed in English itself, as non of the default languages set for any of the courses should have any role.

<b>Scenario 4</b>

1. Log in to Expertiza as a student.

2. Go to the “user profile” page and change “preferred language” to Hindi.

3. Go to a page where translation keys aren’t added completely and make sure that the unspecified keys display strings in English as a fallback.

== Future Scope==
'''1. Expand to more languages'''<br>
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'''<br>
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 [[mailto:rmjohn2@ncsu.edu rmjohn2@ncsu.edu]]<br>
Renji Joseph Sabu [[mailto:rsabu@ncsu.edu rsabu@ncsu.edu]]<br>
Ashwin Das [[mailto:adas9@ncsu.edu adas9@ncsu.edu]]<br>
Arnav Julka [[mailto:ajulka@ncsu.edu ajulka@ncsu.edu]]<br>

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T03:26:43Z

Ajulka: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T03:26:28Z

Ajulka: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:49:49Z

Ajulka: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:49:32Z

Ajulka: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:49:17Z

Ajulka: /* Introduction - Purpose & Problem */

File:Twophase2.jpg

2021-11-03T01:48:16Z

Ajulka:

File:Twophase.png

2021-11-03T01:45:30Z

Ajulka:

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:44:18Z

Ajulka: /* Major design patterns and principles used */

File:Chainofresp.png

2021-11-03T01:43:47Z

Ajulka:

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:43:35Z

Ajulka: /* Major design patterns and principles used */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:39:50Z

Ajulka: /* Design */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:39:25Z

Ajulka: /* Design */

File:I18n.png

2021-11-03T01:38:55Z

Ajulka: Ajulka uploaded a new version of File:I18n.png

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:38:05Z

Ajulka: /* Design */

File:I18n.png

2021-11-03T01:37:26Z

Ajulka:

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:29:00Z

Ajulka: /* Design */

== Introduction - Purpose & Problem ==
1. Language selection
<br><br>
'''''2 Rendering the language'''''<br>
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection

<br><br>
'''''2. Rendering the language'''''<br>
Rendering the language<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale).
[[File:Example.jpg]]
For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>
'''''3. Translation gaps'''''
<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
@ajulka

'''3, Do we store the language preference, in the session or in the database?'''<br>
@rsabu

== Use Case Diagram ==
== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
@ajulka

'''3. Open closed principle & Strategy Pattern'''<br>
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'''<br>
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'''<br>
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 [[mailto:rmjohn2@ncsu.edu rmjohn2@ncsu.edu]]<br>
Renji Joseph Sabu [[mailto:rsabu@ncsu.edu rsabu@ncsu.edu]]<br>
Ashwin Das [[mailto:adas9@ncsu.edu adas9@ncsu.edu]]<br>
Arnav Julka [[mailto:ajulka@ncsu.edu ajulka@ncsu.edu]]<br>

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:28:02Z

Ajulka: /* Design */

== Introduction - Purpose & Problem ==
1. Language selection
<br><br>
'''''2 Rendering the language'''''<br>
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection

<br><br>
'''''2. Rendering the language'''''<br>
Rendering the language<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale).

For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>

'''''3. Translation gaps'''''

<br>Also, if the language is set to be Hindi or any other language but the key-value pair is not set for that particular string then, automatically the library returns the default which is the English text.<br><pre>config.i18n.fallbacks = [:en]</pre>

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
@ajulka

'''3, Do we store the language preference, in the session or in the database?'''<br>
@rsabu

== Use Case Diagram ==
== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
@ajulka

'''3. Open closed principle & Strategy Pattern'''<br>
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'''<br>
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'''<br>
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 [[mailto:rmjohn2@ncsu.edu rmjohn2@ncsu.edu]]<br>
Renji Joseph Sabu [[mailto:rsabu@ncsu.edu rsabu@ncsu.edu]]<br>
Ashwin Das [[mailto:adas9@ncsu.edu adas9@ncsu.edu]]<br>
Arnav Julka [[mailto:ajulka@ncsu.edu ajulka@ncsu.edu]]<br>

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:26:07Z

Ajulka: /* Design */

== Introduction - Purpose & Problem ==
1. Language selection
<br><br>
'''''2 Rendering the language'''''<br>
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection

<br><br>
'''''2. Rendering the language'''''<br>
Rendering the language<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

<br><br><pre></pre>

'''''I18n - Internationalisation, How are we using I18n in Ruby on Rail'''''<br>
I18n is a ruby library/gem which helps us render the static string on the view dynamically. Dynamicity means that based on a local decision of choosing the current language of the view, the library returns the strings of that particular language at runtime.<br>

<br>
These strings, instead of hardcoding in the view.rb, are provided in external .yml files. Now at the View level, we can pass an id to the 't' function and the I18n library returns the string for that id of the current set language(called as locale).

For this purpose, we have to provide .yml files for each language and in those language-specific .yml, we have to provide a map of key-value pairs where the key is the id of the string and value is the string in that particular language. By default the language or locale is set to be English(:en).
<br>
THE GREATEST BENEFITS of using this library are - <br>
*The strings aren't hardcoded in the code/build. The strings are being fetched from external files which can be easily modified. For example, if one needs to change the text from 'Please Help' to 'Help', then one just needs to make a change in the .yml file and the change would reflect on the browser. For this change, we didn't need to redeploy the server. We just Decoupled the view when and where from what content is to be shown.
*Adding more languages is now super easy. Adding support for another language is just one line change in the config and adding a .yml file (having all the key-value pairs for the strings) for the new language. By doing this we can extend the language support as much as we want.
<br>

3. Translation gaps

== Alternate approaches ==

'''1. Why not simply swap out the entire view for another language instead of each text?'''<br>
A view is an organized collection of multiple separate elements, views often involve dynamic generation and some level of sophistication. If we were to swap out one page in its entirety for another page this would often violate the '''DRY''' principle since we would have to have two separate implementations of the view in each language. Thus in the worst case, you have a complex view that has to be replicated dozens of times in various languages.
The majority of complexity of the page is not in the content itself but rather the code that executes to generate that content, thus it makes sense to instead maintain a single view and embed the language switching logic at each location where translation needs to occur to avoid replication of everything around it.

'''2. Why did we pick i18n over implementing it ourselves?'''<br>
@ajulka

'''3, Do we store the language preference, in the session or in the database?'''<br>
@rsabu

== Use Case Diagram ==
== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
@ajulka

'''3. Open closed principle & Strategy Pattern'''<br>
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'''<br>
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'''<br>
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 [[mailto:rmjohn2@ncsu.edu rmjohn2@ncsu.edu]]<br>
Renji Joseph Sabu [[mailto:rsabu@ncsu.edu rsabu@ncsu.edu]]<br>
Ashwin Das [[mailto:adas9@ncsu.edu adas9@ncsu.edu]]<br>
Arnav Julka [[mailto:ajulka@ncsu.edu ajulka@ncsu.edu]]<br>

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:23:03Z

Ajulka: /* Design */

== Introduction - Purpose & Problem ==
1. Language selection
<br><br>
'''''2 Rendering the language'''''<br>
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection
<br><br>
'''''2. Rendering the language'''''<br>
Rendering the language<br>
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:<br>
<pre><h2>Summary Report for assignment: <%= @assignment.name %></h2>
<h4>Team: <%= @team.name %></h4></pre>
<br>
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):<br>
<pre><h2>Rapport de synthèse pour l'affectation: <%= @assignment.name %></h2>
<h4>Équipe: <%= @team.name %></h4></pre>

<br>Instead, the better approach is to have a single unified view that dynamically changes based on the selected language:<br><pre><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></pre>

<br>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:<br><pre><h2><%=localized(“report_summary.page_header”)>: <%= @assignment.name %></h2>
<h4><%=localized(“report_summary.team_label”)>: <%= @team.name %></h4></pre>
<br>Here the assumption is that the localized(“key”) is aware of the currently selected language and that “report_summary.page_header” is the key for the header which is available in English and Hindi. The helper intelligently selects and returns the right text based on the currently selected language. Through this approach, we are able to render the view in multiple possible languages without any significant increase in the verbosity of the view.

What’s more, is that the above problem is a common problem for user-facing applications and a standard library for doing the above and much more already exists for rails applications called i18n
<br>

<br><br><pre></pre>

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

== Alternate approaches ==
== Use Case Diagram ==
== Major design patterns and principles used ==

'''1. DRY: The i18n ‘t’ function'''<br>
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'''<br>
@ajulka

'''3. Open closed principle & Strategy Pattern'''<br>
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'''<br>
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'''<br>
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 [[mailto:rmjohn2@ncsu.edu rmjohn2@ncsu.edu]]<br>
Renji Joseph Sabu [[mailto:rsabu@ncsu.edu rsabu@ncsu.edu]]<br>
Ashwin Das [[mailto:adas9@ncsu.edu adas9@ncsu.edu]]<br>
Arnav Julka [[mailto:ajulka@ncsu.edu ajulka@ncsu.edu]]<br>

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:22:23Z

Ajulka: /* Design */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:19:51Z

Ajulka: /* Design */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:18:58Z

Ajulka: /* Design */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:16:40Z

Ajulka: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:16:28Z

Ajulka: /* Introduction - Purpose & Problem */

== Introduction - Purpose & Problem ==
1. Language selection
<br><br>
'''''2 Rendering the language'''''<br><br
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection
2. Rendering the language
I18n - Internationalisation, How are we using I18n in Ruby on Rails 7
3. Translation gaps
== Alternate approaches ==
== Use Case Diagram ==
== Major design patterns and principles used ==
== Database Design ==
Database Modification ==
== Test Plan ==
Test Details
Manual Testing
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
== Future Scope==
== Team ==

'''Team Members'''

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

'''Mentor'''

Jialin Cui [[mailto:jcui9@ncsu.edu jcui9@ncsu.edu]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:16:13Z

Ajulka: /* Introduction - Purpose & Problem */

== Introduction - Purpose & Problem ==
1. Language selection
<br>
'''''2 Rendering the language'''''<br><br>
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection
2. Rendering the language
I18n - Internationalisation, How are we using I18n in Ruby on Rails 7
3. Translation gaps
== Alternate approaches ==
== Use Case Diagram ==
== Major design patterns and principles used ==
== Database Design ==
Database Modification ==
== Test Plan ==
Test Details
Manual Testing
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
== Future Scope==
== Team ==

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:15:54Z

Ajulka: /* Introduction - Purpose & Problem */

== Introduction - Purpose & Problem ==
1. Language selection

'''''2 Rendering the language'''''<br>
'''How do we go about rendering the screen in that language?''' <br>
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:<br>
'''Views are composed of independent language elements'''<br>
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.
<br>
'''*Views require translation at a large number of call sites'''<br>
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

== Scope ==
== Design ==
Proposed Solution
1. Language selection
2. Rendering the language
I18n - Internationalisation, How are we using I18n in Ruby on Rails 7
3. Translation gaps
== Alternate approaches ==
== Use Case Diagram ==
== Major design patterns and principles used ==
== Database Design ==
Database Modification ==
== Test Plan ==
Test Details
Manual Testing
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
== Future Scope==
== Team ==

CSC/ECE 517 Fall 2021

2021-11-03T01:07:22Z

Ajulka: /* Final Projects */

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [[CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring & Grades]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]

E2159 Expertiza internationalization

2021-11-03T01:05:50Z

Ajulka: Ajulka moved page E2159 Expertiza internationalization to CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

#REDIRECT [[CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:05:50Z

Ajulka: Ajulka moved page E2159 Expertiza internationalization to CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

== Introduction - Purpose & Problem ==
1. Language selection
2. Rendering the language
3. Translation gaps

== Scope ==
Design 5
Proposed Solution 5
Language selection 5
Rendering the language 6
I18n - Internationalisation, How are we using I18n in Ruby on Rails 7
Translation gaps 8
Alternate approaches 8
Use Case Diagram 9
Major design patterns and principles used 9
Database Design 10
Database Modification 10
Test Plan 12
Test Details 12
Manual Testing 12
Scenario 1 12
Scenario 2 13
Scenario 3 13
Scenario 4 13
Scenario 5 13
UI Testing 14
Automated testing using Rspec 14
Future Scope 14
Team

CSC/ECE 517 Fall 2021

2021-11-03T01:02:53Z

Ajulka: /* Final Projects */

CSC/ECE 517 Fall 2021

2021-11-03T01:02:14Z

Ajulka: /* Final Projects */

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [[CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring & Grades]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
[[https://expertiza.csc.ncsu.edu/index.php/E2159_Expertiza_internationalization]]

CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization

2021-11-03T01:00:51Z

Ajulka: E2159 Expertiza internationalization

heloooooo

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-20T23:57:03Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

=E2142. Improve e-mail notifications=

==Work in progress==
This project is ongoing, and this page will be updated live.

== Issue - Don't send email to reviewers for a new submission after the review deadline has passed ==

'''Pre conditions'''
* There is an assignment, a student as a participant, a participant as a reviewer who is reviewing the this particular assignment
* a review is made for a submission by the student
* review deadline has passed
* the student is allowed to submit after the review deadline has passed

'''Expected Behavior'''

Exact issue stating the expected behavior can be found at https://github.com/expertiza/expertiza/issues/345 -
"Evidently, if a submission is revised after review, the system e-mails the reviewer saying to revise the review. This is just fine ... except if the last round of review has been completed.
The message telling reviewers to revise their reviews should not be sent after the last review deadline has passed."

So basically, When the student makes a new submission after the LAST review deadline has passed. The reviewer should not receive an email, asking the reviewer to update the review according to the new submission.

'''Actual Behavior'''

According to the current Code scenario on the beta branch '''''if the deadline has passed, a student(participant) cannot make new submissions'''''. So, automatically if the participant doe not make a new submission then the reviewer wont receive an email. So this issue does not really exist by the virtue of the state of the system.
the stack trace for the check if the submission is allowed or not is as follows -
assignment.rb
<pre>
def submission_allowed(topic_id = nil)
check_condition('submission_allowed_id', topic_id)
end
</pre>

assignment.rb
<pre>
def check_condition(column, topic_id = nil)
next_due_date = DueDate.get_next_due_date(self.id, topic_id)
return false if next_due_date.nil?
right_id = next_due_date.send column
right = DeadlineRight.find(right_id)
right && (right.name == 'OK' || right.name == 'Late')
end
</pre>

due_date.rb
<pre>
def self.get_next_due_date(assignment_id, topic_id = nil)
if Assignment.find(assignment_id).staggered_deadline?
next_due_date = TopicDueDate.find_by(['parent_id = ? and due_at >= ?', topic_id, Time.zone.now])
# if certion TopicDueDate is not exist, we should query next corresponding AssignmentDueDate.
# eg. Time.now is 08/28/2016
# One topic uses following deadlines:
# TopicDueDate 08/01/2016
# TopicDueDate 08/02/2016
# TopicDueDate 08/03/2016
# AssignmentDueDate 09/04/2016
# In this case, we cannot find due_at later than Time.now in TopicDueDate.
# So we should find next corrsponding AssignmentDueDate, starting with the 4th one, not the 1st one!
if next_due_date.nil?
topic_due_date_size = TopicDueDate.where(parent_id: topic_id).size
following_assignment_due_dates = AssignmentDueDate.where(parent_id: assignment_id)[topic_due_date_size..-1]
unless following_assignment_due_dates.nil?
following_assignment_due_dates.each do |assignment_due_date|
if assignment_due_date.due_at >= Time.zone.now
next_due_date = assignment_due_date
break
end
end
end
end
else
next_due_date = AssignmentDueDate.find_by(['parent_id = ? && due_at >= ?', assignment_id, Time.zone.now])
end
next_due_date
end
</pre>

So this is issue is resolved by the state of the system itself.<br>
'''''BUT Surprisingly on beta branch Reviewers aren't getting any emails at all'''''
on beta branch, in submitted_content_controller, in function "submit_file", this lines is supposed to send email to the reviewers to notify them about the new submission
<pre> participant.assignment.email(participant.id) rescue nil </pre>
''BUT'' here email function is undefined. we checked for email function in assignment class, there was none. The error "undefined function on assignment" is always rescued and hence no errors were raised previously and hence it wasn't highlighted before. <br>
So, in beta branch reviewers are not being notified anytime a new submission is made to an assignment that they have previously reviewed. So we fixed that
Taking inspiration from the Master branch the previous team's work we added following code to send an email notifying the reviewer of an new submission.

in submitted_content_controller.rb, in the functions, submit_file, submit_hyperlink
<pre>
Team.mail_assigned_reviewers(@participant)
</pre>

participant.rb

<pre>
def mail_assigned_reviewers()
team = self.team
maps = ResponseMap.where(reviewed_object_id: self.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
reviewer = User.find(Participant.find(map.reviewer_id).user_id)
Mailer.sync_message(
{
:to => reviewer.email,
subject: "Assignment '#{self.assignment.name}': A submission has been updated since you last reviewed it",
cc: User.find_by(self.assignment.instructor_id).email,
:body => {
:obj_name => self.assignment.name,
:link => "https://expertiza.ncsu.edu/response/new?id=#{map.id}",
:type => 'submission',
:first_name => ApplicationHelper::get_user_first_name(User.find(Participant.find(map.reviewer_id).user_id)),
:partial_name => 'updated_submission_since_review'
}
}
).deliver_now
end
end
end
</pre>

app/views/mailer/partials/_updated_submission_since_review_plain.html.erb
<pre>
Hi <%= @first_name %>,

A <%=@type%> you were reviewing for Assignment '<%= @obj_name %>' has been updated since you last review.
Hence, to update your review please click on the following link.
<% if @link != nil %><%= @link %><% end %>
</pre>

app/views/mailer/partials/_updated_submission_since_review_html.html.erb
<pre>
Hi <%= @first_name %>,</br>
<p>
A <%=@type%> you were reviewing for Assignment '<%= @obj_name %>' has been updated since you last review.<br>
Hence, to update your review please click on the following link.<br>
<% if @link != nil %><a href="<%= @link %>"><%= @link %></a><% end %>
</p>
</pre>

added a line in app/mailers/mailer.rb
<pre>
@link = defn[:body][:link]
</pre>

----

==Testing==
'''Testing Reviewe's Email manually'''

Step 1: Create new assignment [Manage --> Assignment --> + Button (to create new assignment)]

Step 2: Fill the details for the assignments.

Step 3: Navigate to due dates.

Step 4: Change the number of review rounds to 2.

Step 5: Select "Yes" in the dropdown for review allowed during submission and select "Yes" for submission during the review.

Step 6: Add two users to the assignment(author and reviewer).

Step 7: Log in with some user credentials (author credential).

Step 8: Make a new submission to this assignment.

Step 9: Log in with another user (reviewer).

Step 10: Submit a review of the assignment submission.

Step 11: Login as an author again.

Step 12: Edit the submission.

Step 13: After this check the mailbox of the reviewer [development mail for development].

Step 14: Reviewer should get the mail to re-review the work.

Step 15: Change the due date to some date and time which has passed.

Step 16: Now the author should not be able to make a new submission.

'''Testing Reviewe's Email via rspec'''

==Brief Introduction==

* E2142. Improve e-mail notifications
* The forked repository can be found at: https://github.com/griffinbrookshire/expertiza

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T21:25:37Z

Ajulka: /* E2142. Improve e-mail notifications */

=E2142. Improve e-mail notifications=

==Work in progress==
This project is ongoing, and this page will be updated live.

== Issue - Don't send email to reviewers for a new submission after the review deadline has passed ==

'''Pre conditions'''
* There is an assignment, a student as a participant, a participant as a reviewer who is reviewing the this particular assignment
* a review is made for a submission by the student
* review deadline has passed
* the student is allowed to submit after the review deadline has passed

'''Expected Behavior'''

Exact issue stating the expected behavior can be found at https://github.com/expertiza/expertiza/issues/345 -
"Evidently, if a submission is revised after review, the system e-mails the reviewer saying to revise the review. This is just fine ... except if the last round of review has been completed.
The message telling reviewers to revise their reviews should not be sent after the last review deadline has passed."

So basically, When the student makes a new submission after the LAST review deadline has passed. The reviewer should not receive an email, asking the reviewer to update the review according to the new submission.

'''Actual Behavior'''

According to the current Code scenario on the beta branch '''''if the deadline has passed, a student(participant) cannot make new submissions'''''. So, automatically if the participant doe not make a new submission then the reviewer wont receive an email. So this issue does not really exist by the virtue of the state of the system.
the stack trace for the check if the submission is allowed or not is as follows -
assignment.rb
<pre>
def submission_allowed(topic_id = nil)
check_condition('submission_allowed_id', topic_id)
end
</pre>

assignment.rb
<pre>
def check_condition(column, topic_id = nil)
next_due_date = DueDate.get_next_due_date(self.id, topic_id)
return false if next_due_date.nil?
right_id = next_due_date.send column
right = DeadlineRight.find(right_id)
right && (right.name == 'OK' || right.name == 'Late')
end
</pre>

due_date.rb
<pre>
def self.get_next_due_date(assignment_id, topic_id = nil)
if Assignment.find(assignment_id).staggered_deadline?
next_due_date = TopicDueDate.find_by(['parent_id = ? and due_at >= ?', topic_id, Time.zone.now])
# if certion TopicDueDate is not exist, we should query next corresponding AssignmentDueDate.
# eg. Time.now is 08/28/2016
# One topic uses following deadlines:
# TopicDueDate 08/01/2016
# TopicDueDate 08/02/2016
# TopicDueDate 08/03/2016
# AssignmentDueDate 09/04/2016
# In this case, we cannot find due_at later than Time.now in TopicDueDate.
# So we should find next corrsponding AssignmentDueDate, starting with the 4th one, not the 1st one!
if next_due_date.nil?
topic_due_date_size = TopicDueDate.where(parent_id: topic_id).size
following_assignment_due_dates = AssignmentDueDate.where(parent_id: assignment_id)[topic_due_date_size..-1]
unless following_assignment_due_dates.nil?
following_assignment_due_dates.each do |assignment_due_date|
if assignment_due_date.due_at >= Time.zone.now
next_due_date = assignment_due_date
break
end
end
end
end
else
next_due_date = AssignmentDueDate.find_by(['parent_id = ? && due_at >= ?', assignment_id, Time.zone.now])
end
next_due_date
end
</pre>

So this is issue is resolved by the state of the system itself.<br>
'''''BUT Surprisingly on beta branch Reviewers aren't getting any emails at all'''''
on beta branch, in submitted_content_controller, in function "submit_file", this lines is supposed to send email to the reviewers to notify them about the new submission
<pre> participant.assignment.email(participant.id) rescue nil </pre>
''BUT'' here email function is undefined. we checked for email function in assignment class, there was none. The error "undefined function on assignment" is always rescued and hence no errors were raised previously and hence it wasn't highlighted before. <br>
So, in beta branch reviewers are not being notified anytime a new submission is made to an assignment that they have previously reviewed. So we fixed that
Taking inspiration from the Master branch the previous team's work we added following code to send an email notifying the reviewer of an new submission.

in submitted_content_controller.rb, in the functions, submit_file, submit_hyperlink
<pre>
Team.mail_assigned_reviewers(@participant)
</pre>

team.rb

<pre>
def self.mail_assigned_reviewers(participant)
team = participant.team
maps = ResponseMap.where(reviewed_object_id: participant.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
reviewer = User.find(Participant.find(map.reviewer_id).user_id)
Mailer.sync_message(
{
:to => reviewer.email,
subject: "Assignment '#{participant.assignment.name}': A submission has been updated since you last reviewed it",
cc: User.find_by(participant.assignment.instructor_id).email,
:body => {
:obj_name => participant.assignment.name,
:link => "https://expertiza.ncsu.edu/response/new?id=#{map.id}",
:type => 'submission',
:first_name => ApplicationHelper::get_user_first_name(User.find(Participant.find(map.reviewer_id).user_id)),
:partial_name => 'updated_submission_since_review'
}
}
).deliver_now
end
end
end
</pre>

app/views/mailer/partials/_updated_submission_since_review_plain.html.erb
<pre>
Hi <%= @first_name %>,

A <%=@type%> you were reviewing for Assignment '<%= @obj_name %>' has been updated since you last review.
Hence, to update your review please click on the following link.
<% if @link != nil %><%= @link %><% end %>
</pre>

app/views/mailer/partials/_updated_submission_since_review_html.html.erb
<pre>
Hi <%= @first_name %>,</br>
<p>
A <%=@type%> you were reviewing for Assignment '<%= @obj_name %>' has been updated since you last review.<br>
Hence, to update your review please click on the following link.<br>
<% if @link != nil %><a href="<%= @link %>"><%= @link %></a><% end %>
</p>
</pre>

added a line in app/mailers/mailer.rb
<pre>
@link = defn[:body][:link]
</pre>

----

==Testing==
'''Testing Reviewe's Email manually'''

Step 1: Create new assignment [Manage --> Assignment --> + Button (to create new assignment)]

Step 2: Fill the details for the assignments.

Step 3: Navigate to due dates.

Step 4: Change the number of review rounds to 2.

Step 5: Select "Yes" in the dropdown for review allowed during submission and select "Yes" for submission during the review.

Step 6: Add two users to the assignment(author and reviewer).

Step 7: Log in with some user credentials (author credential).

Step 8: Make a new submission to this assignment.

Step 9: Log in with another user (reviewer).

Step 10: Submit a review of the assignment submission.

Step 11: Login as an author again.

Step 12: Edit the submission.

Step 13: After this check the mailbox of the reviewer [development mail for development].

Step 14: Reviewer should get the mail to re-review the work.

Step 15: Change the due date to some date and time which has passed.

Step 16: Now the author should not be able to make a new submission.

'''Testing Reviewe's Email via rspec'''

==Brief Introduction==

* E2142. Improve e-mail notifications
* The forked repository can be found at: https://github.com/griffinbrookshire/expertiza

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T21:22:31Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

=E2142. Improve e-mail notifications=

==Work in progress==
This project is ongoing, and this page will be updated live.

== Issue - Don't send email to reviewers for a new submission after the review deadline has passed ==

'''Pre conditions'''
* There is an assignment, a student as a participant, a participant as a reviewer who is reviewing the this particular assignment
* a review is made for a submission by the student
* review deadline has passed
* the student is allowed to submit after the review deadline has passed

'''Expected Behavior'''

Exact issue stating the expected behavior can be found at https://github.com/expertiza/expertiza/issues/345 -
"Evidently, if a submission is revised after review, the system e-mails the reviewer saying to revise the review. This is just fine ... except if the last round of review has been completed.
The message telling reviewers to revise their reviews should not be sent after the last review deadline has passed."

So basically, When the student makes a new submission after the LAST review deadline has passed. The reviewer should not receive an email, asking the reviewer to update the review according to the new submission.

'''Actual Behavior'''

According to the current Code scenario on the beta branch '''''if the deadline has passed, a student(participant) cannot make new submissions'''''. So, automatically if the participant doe not make a new submission then the reviewer wont receive an email. So this issue does not really exist by the virtue of the state of the system.
the stack trace for the check if the submission is allowed or not is as follows -
assignment.rb
<pre>
def submission_allowed(topic_id = nil)
check_condition('submission_allowed_id', topic_id)
end
</pre>

assignment.rb
<pre>
def check_condition(column, topic_id = nil)
next_due_date = DueDate.get_next_due_date(self.id, topic_id)
return false if next_due_date.nil?
right_id = next_due_date.send column
right = DeadlineRight.find(right_id)
right && (right.name == 'OK' || right.name == 'Late')
end
</pre>

due_date.rb
<pre>
def self.get_next_due_date(assignment_id, topic_id = nil)
if Assignment.find(assignment_id).staggered_deadline?
next_due_date = TopicDueDate.find_by(['parent_id = ? and due_at >= ?', topic_id, Time.zone.now])
# if certion TopicDueDate is not exist, we should query next corresponding AssignmentDueDate.
# eg. Time.now is 08/28/2016
# One topic uses following deadlines:
# TopicDueDate 08/01/2016
# TopicDueDate 08/02/2016
# TopicDueDate 08/03/2016
# AssignmentDueDate 09/04/2016
# In this case, we cannot find due_at later than Time.now in TopicDueDate.
# So we should find next corrsponding AssignmentDueDate, starting with the 4th one, not the 1st one!
if next_due_date.nil?
topic_due_date_size = TopicDueDate.where(parent_id: topic_id).size
following_assignment_due_dates = AssignmentDueDate.where(parent_id: assignment_id)[topic_due_date_size..-1]
unless following_assignment_due_dates.nil?
following_assignment_due_dates.each do |assignment_due_date|
if assignment_due_date.due_at >= Time.zone.now
next_due_date = assignment_due_date
break
end
end
end
end
else
next_due_date = AssignmentDueDate.find_by(['parent_id = ? && due_at >= ?', assignment_id, Time.zone.now])
end
next_due_date
end
</pre>

So this is issue is resolved by the state of the system itself.<br>
'''''BUT Surprisingly on beta branch Reviewers aren't getting any emails at all'''''
on beta branch, in submitted_content_controller, in function "submit_file", this lines is supposed to send email to the reviewers to notify them about the new submission
<pre> participant.assignment.email(participant.id) rescue nil </pre>
''BUT'' here email function is undefined. we checked for email function in assignment class, there was none. The error "undefined function on assignment" is always rescued and hence no errors were raised previously and hence it wasn't highlighted before. <br>
So, in beta branch reviewers are not being notified anytime a new submission is made to an assignment that they have previously reviewed. So we fixed that
Taking inspiration from the Master branch the previous team's work we added following code to send an email notifying the reviewer of an new submission.

in submitted_content_controller.rb, in the functions, submit_file, submit_hyperlink
<pre>
Team.mail_assigned_reviewers(@participant)
</pre>

team.rb

<pre>
def self.mail_assigned_reviewers(participant)
team = participant.team
maps = ResponseMap.where(reviewed_object_id: participant.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
reviewer = User.find(Participant.find(map.reviewer_id).user_id)
Mailer.sync_message(
{
:to => reviewer.email,
subject: "Assignment '#{participant.assignment.name}': A submission has been updated since you last reviewed it",
cc: User.find_by(participant.assignment.instructor_id).email,
:body => {
:obj_name => participant.assignment.name,
:link => "https://expertiza.ncsu.edu/response/new?id=#{map.id}",
:type => 'submission',
:first_name => ApplicationHelper::get_user_first_name(User.find(Participant.find(map.reviewer_id).user_id)),
:partial_name => 'updated_submission_since_review'
}
}
).deliver_now
end
end
end
</pre>

app/views/mailer/partials/_updated_submission_since_review_plain.html.erb
<pre>
Hi <%= @first_name %>,

A <%=@type%> you were reviewing for Assignment '<%= @obj_name %>' has been updated since you last review.
Hence, to update your review please click on the following link.
<% if @link != nil %><%= @link %><% end %>
</pre>

app/views/mailer/partials/_updated_submission_since_review_html.html.erb
<pre>
Hi <%= @first_name %>,</br>
<p>
A <%=@type%> you were reviewing for Assignment '<%= @obj_name %>' has been updated since you last review.<br>
Hence, to update your review please click on the following link.<br>
<% if @link != nil %><a href="<%= @link %>"><%= @link %></a><% end %>
</p>
</pre>

added a line in app/mailers/mailer.rb
<pre>
@link = defn[:body][:link]
</pre>

==Brief Introduction==

* E2142. Improve e-mail notifications
* The forked repository can be found at: https://github.com/griffinbrookshire/expertiza

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T21:04:53Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

=E2142. Improve e-mail notifications=

==Work in progress==
This project is ongoing, and this page will be updated live.

== Issue - Don't send email to reviewers for a new submission after the review deadline has passed ==

'''Pre conditions'''
* There is an assignment, a student as a participant, a participant as a reviewer who is reviewing the this particular assignment
* a review is made for a submission by the student
* review deadline has passed
* the student is allowed to submit after the review deadline has passed

'''Expected Behavior'''

Exact issue stating the expected behavior can be found at https://github.com/expertiza/expertiza/issues/345 -
"Evidently, if a submission is revised after review, the system e-mails the reviewer saying to revise the review. This is just fine ... except if the last round of review has been completed.
The message telling reviewers to revise their reviews should not be sent after the last review deadline has passed."

So basically, When the student makes a new submission after the LAST review deadline has passed. The reviewer should not receive an email, asking the reviewer to update the review according to the new submission.

'''Actual Behavior'''

According to the current Code scenario on the beta branch '''''if the deadline has passed, a student(participant) cannot make new submissions'''''. So, automatically if the participant doe not make a new submission then the reviewer wont receive an email. So this issue does not really exist by the virtue of the state of the system.
the stack trace for the check if the submission is allowed or not is as follows -
assignment.rb
<pre>
def submission_allowed(topic_id = nil)
check_condition('submission_allowed_id', topic_id)
end
</pre>

assignment.rb
<pre>
def check_condition(column, topic_id = nil)
next_due_date = DueDate.get_next_due_date(self.id, topic_id)
return false if next_due_date.nil?
right_id = next_due_date.send column
right = DeadlineRight.find(right_id)
right && (right.name == 'OK' || right.name == 'Late')
end
</pre>

due_date.rb
<pre>
def self.get_next_due_date(assignment_id, topic_id = nil)
if Assignment.find(assignment_id).staggered_deadline?
next_due_date = TopicDueDate.find_by(['parent_id = ? and due_at >= ?', topic_id, Time.zone.now])
# if certion TopicDueDate is not exist, we should query next corresponding AssignmentDueDate.
# eg. Time.now is 08/28/2016
# One topic uses following deadlines:
# TopicDueDate 08/01/2016
# TopicDueDate 08/02/2016
# TopicDueDate 08/03/2016
# AssignmentDueDate 09/04/2016
# In this case, we cannot find due_at later than Time.now in TopicDueDate.
# So we should find next corrsponding AssignmentDueDate, starting with the 4th one, not the 1st one!
if next_due_date.nil?
topic_due_date_size = TopicDueDate.where(parent_id: topic_id).size
following_assignment_due_dates = AssignmentDueDate.where(parent_id: assignment_id)[topic_due_date_size..-1]
unless following_assignment_due_dates.nil?
following_assignment_due_dates.each do |assignment_due_date|
if assignment_due_date.due_at >= Time.zone.now
next_due_date = assignment_due_date
break
end
end
end
end
else
next_due_date = AssignmentDueDate.find_by(['parent_id = ? && due_at >= ?', assignment_id, Time.zone.now])
end
next_due_date
end
</pre>

So this is issue is resolved by the state of the system itself.<br>
'''''BUT Surprisingly on beta branch Reviewers aren't getting any emails at all'''''
on beta branch, in submitted_content_controller, in function "submit_file", this lines is supposed to send email to the reviewers to notify them about the new submission
<pre> participant.assignment.email(participant.id) rescue nil </pre>
''BUT'' here email function is undefined. we checked for email function in assignment class, there was none. The error "undefined function on assignment" is always rescued and hence no errors were raised previously and hence it wasn't highlighted before. <br>
So, in beta branch reviewers are not being notified anytime a new submission is made to an assignment that they have previously reviewed. So we fixed that
Taking inspiration from the Master branch the previous team's work we added following code to send an email notifying the reviewer of an new submission.

in submitted_content_controller.rb, in the functions, submit_file, submit_hyperlink
<pre>
Team.mail_assigned_reviewers(@participant)
</pre>

team.rb

<pre>
def self.mail_assigned_reviewers(participant)
team = participant.team
maps = ResponseMap.where(reviewed_object_id: participant.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
reviewer = User.find(Participant.find(map.reviewer_id).user_id)
Mailer.sync_message(
{
:to => reviewer.email,
subject: "Assignment '#{participant.assignment.name}': A submission has been updated since you last reviewed it",
cc: User.find_by(participant.assignment.instructor_id).email,
:body => {
:obj_name => participant.assignment.name,
:link => "https://expertiza.ncsu.edu/response/new?id=#{map.id}",
:type => 'submission',
:first_name => ApplicationHelper::get_user_first_name(User.find(Participant.find(map.reviewer_id).user_id)),
:partial_name => 'updated_submission_since_review'
}
}
).deliver_now
end
end
end
</pre>

==Brief Introduction==

* E2142. Improve e-mail notifications
* The forked repository can be found at: https://github.com/griffinbrookshire/expertiza

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T20:57:52Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T20:50:28Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T20:49:39Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T20:29:43Z

Ajulka: /* Issue - Don't send email to reviewers for a new submission after the review deadline has passed */

CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications

2021-10-19T19:03:39Z

Ajulka: /* Work in progress */

=E2142. Improve e-mail notifications=

==Work in progress==
This project is ongoing, and this page will be updated live.

== Issue - Don't send email to reviewers for a new submission after the review deadline has passed ==

==Brief Introduction==

* E2142. Improve e-mail notifications
* The forked repository can be found at: https://github.com/griffinbrookshire/expertiza

User:Ajulka

2021-10-11T16:08:50Z

Ajulka: Blanked the page

User:Ajulka

2021-10-11T16:07:21Z

Ajulka: Created page with "E2142. Improve e-mail notifications"

E2142. Improve e-mail notifications