Difference between revisions of "Pseudo Localization"
(Created page with "== config_pseudo_loc.xml.xml == File '''<code>config_pseudo_loc.xml</code>''' is the configuration file for setting up pseudo localization instructions for LRM resource files....") |
(→Video) |
||
(49 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | == Video == |
||
− | == config_pseudo_loc.xml.xml == |
||
+ | For an introduction video on the subject, please see: |
||
− | File '''<code>config_pseudo_loc.xml</code>''' is the configuration file for setting up pseudo localization instructions for LRM resource files. It is located in the global '''<code><HOME>/Lingoport_Data/L10nStreamlining/config</code>''' folder. If you need different criteria for a group or project then the file can be copied and moved to '''<code><HOME>/Lingoport_Data/L10nStreamlining/<group>/config</code>''' or '''<code><HOME>/Lingoport_Data/L10nStreamlining/<group>/projects/<project>config</code>''' respectively. |
||
+ | [[File:Pseudo-Localization Thumbnail.jpg|200px|link=https://www.youtube.com/watch?v=EdJ-oPhP0CY&ab_channel=Lingoport]] |
||
− | The '''config_pseudo_loc.xml''' file is used when running the <code>--pseudo-loc</code> command. A pseudo-localized file will be created for each base resource file if the project has a designated pseudo-locale. |
||
+ | which covers the topic on this Wiki page. |
||
− | There are 2 categories of information contained in the ''config_pseudo_loc.xml'' file. |
||
− | * pseudo localization instructions |
||
− | * regex pattern for each parser type defining the parameters as well as special characters that should not be pseudo-localized. |
||
+ | == What is Pseudo-Localization? == |
||
− | === Pseudo Localization Instructions === |
||
+ | Pseudo-localization is an effective way to test the localization-readiness of an application. By pseudo-localizing the resource files, an application can be tested for internationalization without waiting for localization. |
||
− | The configuration consists of the following xml elements: |
||
− | * '''expansion lengths''' - defines the expansion percentage based on a strings length. This is useful to test language expansions. |
||
− | * '''expansion character''' - the character that will be used to pad the string in order to simulate string expansion |
||
− | * ''expansion end character'' - characters at the end of expansion. Typically, these are symbols across a range of codepoints in order to ensure that content from the various code pages are supported |
||
− | * ''start and end characters'' - characters at the start and end of the resource string. This is useful to catch resource strings that are concatenated within the code. |
||
− | * '''accents''' - a flag indicating whether the resource string should be accented. This is needed to ensure that all visible user strings are localized. |
||
+ | A '''pseudo-locale''' is like a regular locale, like de-DE for German translation, but instead of a translation, it modified the source strings in the following way: |
||
− | The first step in configuring the global email file is to verify, with your IT department, the mail server credentials. |
||
− | [[Sending_Emails#Send_Email_Command|Send email command]] may be used to test the configuration values. |
||
+ | A source string like: |
||
− | ==== Example No Authorization Email Configuration ==== |
||
+ | * '''Order placed successfully!''' |
||
− | Test your email configuration using the [[Sending_Emails#Sending_Email_with_SMTP_protocol_and_no_authorization | -se command for no authorization]]. |
||
+ | will be localized as: |
||
+ | * '''[Öŕðéŕ þļåçéð šûççéššƒûļļý!------------- П國カ내]''' |
||
− | <smtp-host>smtp.gmail.com/<smtp-host> |
||
− | <smtp-auth>'''none'''</smtp-auth> |
||
− | <email-sender>joe@mycompany.com</email-sender> |
||
− | <sender-password encrypted="false">mypassword</sender-password> |
||
+ | The pseudo-localize accented string is still legible, so the developer or QA can run the application. A start character, [, is added at the beginning of the string. The string is expanded to reflect possible width of target locales strings. Some characters from other writing systems are added to check for encoding or font issues. An end character, ], is added to show there that the source string ends to help detect concatenations. |
||
− | ==== Example SMTP Authorization Email Configuration ==== |
||
− | Test your email configuration using the [[Sending_Emails#Sending_Email_with_SMTP_authorization | -se command for SMTP authorization]]. |
||
+ | When the application uses the pseudo-locale, the pseudo-localized resource text will be displayed. |
||
− | <smtp-host>smtp.gmail.com/<smtp-host> |
||
− | <smtp-auth>'''mail.smtp.auth'''</smtp-auth> |
||
− | <email-sender>joe@mycompany.com</email-sender> |
||
− | <sender-password encrypted="false"></sender-password> |
||
+ | Creating pseudo-localized resource files help test for |
||
− | ==== Example SMTPS Authorization Email Configuration ==== |
||
+ | * embedded strings, |
||
− | Test your email configuration using the [[Sending_Emails#Sending_Email_with_SMTPS_protocol|-se command for SMTPS authorization]]. |
||
+ | * text that was externalized but should not be, |
||
+ | * text expansion issues, |
||
+ | * character-encoding problems, |
||
+ | * text concatenation issues, and |
||
+ | * UI boundary issues can be identified. |
||
+ | An application typically retrieves strings based on a locale, such as French. A pseudo-locale is like a normal locale, but the strings are not translated, they simply show differently. |
||
− | <smtp-host>smtp.gmail.com/<smtp-host> |
||
− | <smtp-auth>'''mail.smtps.auth'''</smtp-auth> |
||
− | <email-sender>joe@mycompany.com</email-sender> |
||
− | <sender-password encrypted="false">mypassword</sender-password> |
||
+ | == How to identify i18n Issues with Pseudo-localization == |
||
− | === Additional Email Configuration === |
||
+ | This section shows how to use pseudo-localization to find and correct issues. |
||
− | In addition, there are configuration settings for when to send out notification emails and whether or not to send out the 'No Files to Prep' email. |
||
− | * '''dashboard-url''' - Dashboard URL used as the link destination for the email Log In button |
||
− | * '''notify-changes-email-interval''' - By default, the ''Notification'' email may be sent every day. Since the project's Jenkins Notification job is only run once a week, this email will only be set out once a week. |
||
− | * '''late-kits-email-interval''' - By default, the ''Late Prep Kits'' email may be sent every day depending on the number of days late. Since the project's Jenkins Notification job is only run once a week, this email will be sent out once a week. |
||
− | * '''number-days-late''' - By default, a prep kit is deemed late if it is 7 days late. |
||
− | * '''send-no-files-to-prep-email''' - By default, the ''No Files to Prep'' email will be sent out when there is a request to prep a kit but there are no files to prep. If a Jenkins job is created that automatically attempts to prep a kit, then this value should be set to ''0'' so that the email is not sent. Otherwise, the email recipient's inbox may be inundated with 'No Files to Prep' emails. |
||
− | === |
+ | === UI in the source Locale === |
− | The <code><sender-password></code> can be configured with the <code>encrypted</code> attribute set to true, as in |
||
− | <pre> |
||
− | ... |
||
− | <email-sender>mailuser@company.com</email-sender> |
||
− | <sender-password encrypted="true">UUIasd455</sender-password> |
||
− | ... |
||
− | </pre> |
||
+ | First, let's show the user interface in the source locale, here English/US: |
||
− | To encrypt the password, use the <code>encrypt</code> command line on <code>lrm-common.jar</code> file. For instance: |
||
+ | [[File:Source Locale UI.jpg|center|700px]] |
||
− | '''<code>> java -jar <LRM_INSTALLATION_PATH>/lib/lpcommon.jar --encrypt</code>''' |
||
− | which will prompt you for the text (here the password) to encrypt and will provide the result on the console. |
||
+ | === UI in the pseudo-locale with issues === |
||
− | == Java Options for sending emails == |
||
+ | Below, the application is running with the pseudo-locale (for example 'esperanto') and the English strings have been pseudo-localized. |
||
− | It may be necessary to explicitly set the email port and/or STARTTLS flag rather than rely on the default mail server values. In addition, the email session debug mode can be enabled. |
||
− | There are 3 email settings that may be set through java options: |
||
− | * Email Server Port |
||
− | * SMTP STARTTLS enabled |
||
− | * Email Session Debug mode enabled |
||
+ | Some issues can be identified when the application is running using the pseudo-locale: |
||
− | ==== Email Protocol Port Number ==== |
||
− | The expected java option for explicitly setting the protocol port number is: |
||
− | * mail.smtp.port |
||
+ | [[File:Pseudo-Localization Example Issues.jpg|center|700px]] |
||
− | Linux example if setting java options within a shell session. |
||
+ | * <span style="color:red">1 : Truncation</span>: The end characters have been truncated, indicating a likely UI issues around the space set for the text. The UI may need to be refactored to accommodate for longer text in languages such as German. |
||
− | :: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dmail.smtp.port=25'</span> |
||
+ | * <span style="color:red">2 : Mojibake</span>: When the pseudo-localized text is showing as mojibake, such as �, this likely indicates a character encoding or a font issue. The application does not support non ASCII characters or non Latin-1 characters. |
||
+ | * <span style="color:red">3 : Embedded String / Hard Code String</span>: If the text shows in the original source locale, here English, as opposed to being pseudo-localized, it indicates a likely hard coded string which has not been externalized into a resource file. That string cannot be sent to translation and will show in the interface as the original source string. This is a common internationalization issue. |
||
+ | * <span style="color:red">4: Concatenation</span>: The pseudo-localization shows that two strings have been put together to make up ''Y-Wing Galactic Fighter'', since the end character shows up after ''Galactic Fighter'' and a start character shows up before ''Fighter''. |
||
+ | === UI in the pseudo-locale without issues === |
||
− | === Enable/Disable STARTTLS === |
||
+ | If the i18n issues above were corrected, running the application using the pseudo-locale would look like the following: |
||
− | The expected java option for explicitly enabling/disabling STARTTLS is: |
||
− | * mail.smtp.starttls.enable |
||
+ | [[File:Pseudo-Localization No Issues.jpg.png|center|700px]] |
||
− | Linux example if setting java options within a shell session. |
||
+ | == Configuration == |
||
− | :: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dmail.smtp.starttls.enable=true'</span> |
||
+ | Localyzer makes pseudo-localization quite simple: For the resource files in a repository to be pseudo-localized, edit the Locales by clicking the pseudo-locale checkbox and enter the locale to be used as shown below with '''eo''' (esperanto): |
||
− | STARTTLS is automatically enabled for the SMTPS protocol. |
||
+ | [[File:Pseudo-Localization Configuration.jpg|700px|center]] |
||
− | === Enable Email Session Debug mode === |
||
− | The expected java option for explicitly enabling/disabling the email session debug mode is: |
||
− | * mail.debug.mode |
||
+ | Once this configuration is save, every time the project is analyzed, the resource files will be pseudo-localized. |
||
− | Linux example if setting java options within a shell session. |
||
− | |||
− | :: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dmail.debug.mode=true'</span> |
||
− | |||
− | == Send Email Command == |
||
− | The ''send email command'' is used to test sending an email using your mail server credentials. Before starting, verify with your IT department the mail server credentials otherwise errors will occur. |
||
− | |||
− | The ''send email command'' is accessed through the lpcommon.jar file and is located in the <code>lib</code> folder (i.e. ../lrm-server-x.x/lib). This command is used to test the configured mail server. Before running this command, you may want to [[Sending_Emails#Enable_Email_Session_Debug_mode |enable the email session debug mode]]. |
||
− | |||
− | In order to run the send email <code>-sse</code> or <code>--send-smtp-email</code> command, you must specify an existing location for the error log. |
||
− | |||
− | In addition to the log file, there are 5 other required fields. |
||
− | * '''SMTP Host''' denoted by option <code>-sh</code> or <code>--smtp-host</code> |
||
− | * '''Senders email address''' denoted by option <code>-es</code> or <code>--email-sender</code> |
||
− | * '''Email Subject''' denoted by option <code>-subj</code> or <code>--subject</code> |
||
− | * '''Email Message''' denoted by option <code>-msg</code> or <code>--message</code> |
||
− | * '''Email Recipients''' denoted by option <code>-r</code> or <code>--recipients</code> |
||
− | |||
− | === Sending Email with SMTP protocol and no authorization === |
||
− | To test sending an email using the SMTP protocol with no authorization run the following command: |
||
− | :: <span style="background-color: #eaecf0;>java -jar lpcommon.jar -sse -lf /var/lib/jenkins/test/error.log -sh smtp.gmail.com -es myemail@mycompany.com -subj test -msg "This is a test" -r anotheremail@email.com </span> |
||
− | |||
− | In looking at the console log you should see the following: |
||
− | * Email protocol is `smtp` (which is the default) |
||
− | * Authorization `mail.smtp.auth` is set to `false` |
||
− | |||
− | If errors occurs then you'll need to change your email send options. For error examples see [[Sending_Emails#Error_Messages|Email Error Messages]]. |
||
− | |||
− | === Sending Email with SMTP authorization === |
||
− | To test sending an email using the SMTP protocol with SMTP authorization run the following command: |
||
− | :: <span style="background-color: #eaecf0;>java -jar lpcommon.jar -sse -lf /var/lib/jenkins/test/error.log -sh smtp.gmail.com '''-sa mail.smtp.auth''' -es myemail@mycompany.com -subj test -msg "This is a test" -r anotheremail@email.com </span> |
||
− | |||
− | In looking at the console log you should see the following: |
||
− | * Email protocol is `smtp` |
||
− | * Authorization `mail.smtp.auth` is set to `true` |
||
− | |||
− | If errors occurs then you'll need to change your email send options. For error examples see [[Sending_Emails#Error_Messages|Email Error Messages]]. |
||
− | |||
− | === Sending Email with SMTPS protocol === |
||
− | To test sending an email using the SMTP protocol with SMTP authorization run the following command: |
||
− | :: <span style="background-color: #eaecf0;>java -jar lpcommon.jar -sse -lf /var/lib/jenkins/test/error.log -sh smtp.gmail.com '''-sa mail.smtps.auth''' -es myemail@mycompany.com -subj test -msg "This is a test" -r anotheremail@email.com '''-ep mypassword''' </span> |
||
− | |||
− | In looking at the console log you should see the following: |
||
− | * Email protocol is `smtp` (which is the default) |
||
− | * Authorization `mail.smtp.auth` is set to `false` |
||
− | |||
− | If errors occurs then you'll need to change your email send options. For error examples see [[Sending_Emails#Error_Messages|Email Error Messages]]. |
||
− | |||
− | === Error Messages === |
||
− | The first step in trouble shooting any email messages is to verify, with your IT department, the mail server credentials. |
||
− | |||
− | If you're unable to send an email successfully then you may want to enable the debug mode for the email session. This will provide additional information regarding the progress of the session. Set the debug mode through [[Sending_Emails#Enable_Email_Session_Debug_mode|java options]]. |
||
− | After enabling the debug mode, the error messages should provide explicit information regarding the reason for the failure. There are a few error messages that may not be so obvious. These are: |
||
− | * Connection is not successful due to invalid port number: |
||
− | :: The default port number will be used when setting up the connection. If you're unable to change the default port number then you'll need to explicitly set it via [[Sending_Emails#Email_Protocol_Port_Number|java options]]. |
||
− | * Must issue a STARTTLS command first. This error indicates that STARTTLS must be enabled. This error occurs when the protocol is SMTP. You can attempt to fix this error by: |
||
− | :: Setting the authorization to SMTPS (connection may require a password) |
||
− | ::: or |
||
− | :: Explicitly setting STARTTLS through the java option [[Sending_Emails#Enable.2FDisable_STARTTLS|mail.smtp.starttls.enable]] and adding the password to the command line (<code>-ep</code>) |
Latest revision as of 21:50, 10 April 2024
Contents
Video
For an introduction video on the subject, please see:
which covers the topic on this Wiki page.
What is Pseudo-Localization?
Pseudo-localization is an effective way to test the localization-readiness of an application. By pseudo-localizing the resource files, an application can be tested for internationalization without waiting for localization.
A pseudo-locale is like a regular locale, like de-DE for German translation, but instead of a translation, it modified the source strings in the following way:
A source string like:
- Order placed successfully!
will be localized as:
- [Öŕðéŕ þļåçéð šûççéššƒûļļý!------------- П國カ내]
The pseudo-localize accented string is still legible, so the developer or QA can run the application. A start character, [, is added at the beginning of the string. The string is expanded to reflect possible width of target locales strings. Some characters from other writing systems are added to check for encoding or font issues. An end character, ], is added to show there that the source string ends to help detect concatenations.
When the application uses the pseudo-locale, the pseudo-localized resource text will be displayed.
Creating pseudo-localized resource files help test for
- embedded strings,
- text that was externalized but should not be,
- text expansion issues,
- character-encoding problems,
- text concatenation issues, and
- UI boundary issues can be identified.
An application typically retrieves strings based on a locale, such as French. A pseudo-locale is like a normal locale, but the strings are not translated, they simply show differently.
How to identify i18n Issues with Pseudo-localization
This section shows how to use pseudo-localization to find and correct issues.
UI in the source Locale
First, let's show the user interface in the source locale, here English/US:
UI in the pseudo-locale with issues
Below, the application is running with the pseudo-locale (for example 'esperanto') and the English strings have been pseudo-localized.
Some issues can be identified when the application is running using the pseudo-locale:
- 1 : Truncation: The end characters have been truncated, indicating a likely UI issues around the space set for the text. The UI may need to be refactored to accommodate for longer text in languages such as German.
- 2 : Mojibake: When the pseudo-localized text is showing as mojibake, such as �, this likely indicates a character encoding or a font issue. The application does not support non ASCII characters or non Latin-1 characters.
- 3 : Embedded String / Hard Code String: If the text shows in the original source locale, here English, as opposed to being pseudo-localized, it indicates a likely hard coded string which has not been externalized into a resource file. That string cannot be sent to translation and will show in the interface as the original source string. This is a common internationalization issue.
- 4: Concatenation: The pseudo-localization shows that two strings have been put together to make up Y-Wing Galactic Fighter, since the end character shows up after Galactic Fighter and a start character shows up before Fighter.
UI in the pseudo-locale without issues
If the i18n issues above were corrected, running the application using the pseudo-locale would look like the following:
Configuration
Localyzer makes pseudo-localization quite simple: For the resource files in a repository to be pseudo-localized, edit the Locales by clicking the pseudo-locale checkbox and enter the locale to be used as shown below with eo (esperanto):
Once this configuration is save, every time the project is analyzed, the resource files will be pseudo-localized.