Lingochat | Join L10n Industry Leaders for Peer Discussions

What is Lingochat?

“Lingochat” is a weekly small group discussion, created to share ideas, troubleshoot issues, and help identify to solutions to problems. The groups are intentionally kept small so that everyone has an opportunity to interact and participate, and attendees will primarily be localization specialists and managers. 

There is no cost and the only thing required is that you have a problem you wish to solve, you have solved a problem in your organization, or you wish to brainstorm.  Also, you don’t have to commit to being there every week.  It is just a great way to help each other with solutions.  To join, simply email lingochat@lingoport.com.

A general topic will be published each week as a way to get started.  But what we REALLY want is for the community to suggest topics. 

1st Lingochat Meeting Notes

We had the first Lingochat on the 19th of May, 2020. Below please find the the problems, suggestions, and solutions discussed during the meeting.   

Problem #1

We have a continuous localization process where GitHub is connected to the TMS.

In one product, certain languages require us to deviate from the source content. Our typical issue is between English source and Japanese target.  

We have three different cases:

1. English strings should not show up in the Japanese locale
2. There are Japanese strings that need to be there that do not have English source
   1. This case also requires back-translation (see below)
3. English strings need to have translations that are different

Back-translation:  We currently back translate to English for case 2 because there are times that people in the Japan locale want to view it in English

The way this is handled right now is through override files, and these files contain strings that override the standard strings for specific locales.  But there are many problems with the override files.  They require manual translation and they are hard to maintain over time.

Solution suggestions that could eliminate the override files

1. Cases 1 and 3 above can be solved by simply modifying the target resource file directly.  In case 1, a null string can be inserted.  In case 3, the modified string can be substituted.
2. Case 2 might be solved by simply adding a second string in the resource file that is only used for the specific locale.  This approach would require some i18n code changes.  

Problem #2

We don’t have a good testing process for translated strings.  The way we do it today is to ask development to take screenshots, and we send them to the translators.  With dozens or more locales, this can be a lot of screen shots and we get pushback from development.  One of the key issues is with Thailand and spaces.  Spaces can really cause problems with this language.  This is for both mobile and web applications.  

Solution suggestions

1. Perhaps the screen shot function could be done by a QA or testing organization instead of development.  This might require getting the QA group involved earlier in the process rather than waiting until the localization process is complete.
2. Pseudolocalization might be used early in the process to make sure page spacing is correct prior to translation.  
3. Some TMS products allow “fake” spaces to be inserted that then allow a line break.  This might help.

(Note: Lingoport has software solutions for QA context eliminating screen shot hassles and streamlining fixes, but we do not make LingoChat a sales platform…but sorry, I couldn’t resist.)

Problem #3

How much should be budgeted for fixing internationalization (i18n) issues in source code? Is there a standard on how much it costs to fix bugs?

1. One company did a study on how much it costs to fix an error in the source string when you consider all of the translation work etc.  For example, if there were a missing comma in a source string in a resource file, how much does it cost to fix it for all locales.  That case study was used to help educate the organization on the kind of bugs that should or should not be fixed.
2. Lingoport services routinely fix i18n bugs in source code.  We find that the cost varies quite a bit depending on the approach.  If it is a fairly large number of bugs, the cost per bug can be fairly small.  But if it is only a few bugs, the cost per bug is much higher due to the overhead of code familiarization, setup, testing, and regression testing.  In addition, the cost is very different if the framework is not set up correctly in the first place.  Changes to the architecture take longer.
3. One company assigns points to the bugs.  Developers go through a scrubbing process to make sure the points that are assigned are consistent.  There might be a way to gather some of the point information and convert it to a cost.  

Please email lingochat@lingoport.com if you would like to join a future LingoChat.