localization

Luis Gonçalves - Blog

Agile, scrum, management, leadership

Is Localization delaying your product release?

I want to dedicate this post to a problem that I encounter several times.

  • Did it ever happen to you that localization is the last thing to be done on the project?
  • Was the release of your project delayed because of localization issues?
  • Did your product go live just in English because there was no time to localize it?

In most of the projects localization is still done in “waterfall” mode, all the development is performed without thinking about it. Localization team is involved at a very late stage of the development cycle.

What impact does it have on the product?

In my opinion there are several problems related to it:

1) First it’s almost sure that the product will not be released on time. The team needs to wait for all localization so that the product can be released. Most of the times when the localization is done at the very end the GUI is not taken into account in order to support other languages than English. When the product includes other languages than English, several issues arise that needs to be solved.

2) Linguistic quality will be affected, localization and its testing will be performed in hurry. To perform localization testing GUI specs are needed. Most of the times at the end of the development GUI specs do change so much that no one has the latest version anymore, this will provoke many of the strings not being tested anymore.

As a final outcome, the localization cost will increase in order to correct all the defects inserted during the process. I am sure there are many more problems related to this but I wanted to highlight what are the most critical ones.

How can we improve this situation?

Based on my experience I believe these issues can be drastically reduced if localization is part of the development interactions.

What to change to make this happen?

The first thing to be changed is the people’s mind set. Localization is something that needs to be thought of since the beginning of the development.

The development team (usually called Scrum Team in Scrum World) should always contain a responsible person from the localization department. Developers should prepare the software in a way where resources files are used instead of “hard coded” strings.

The GUI specialist should work closely with the localization team in order to make sure that all the GUI is designed in a way that localization part will not have any big issues. Other languages than English usually take on average 20-30% more space, preparing the GUI for these situations will avoid many truncations issues.

Having localization part of the sprint, allowing localization test cases to be done and updated at the same time as the GUI changes allows the localization team to update the test cases immediately or even source files avoiding futures errors in the process. The projects I have participated it was normal to have test cases or source files out of date because there was not a clear conversation between GUI/development team and localization team.

For last a good way to make localization part of the development is to include it as part of the Definition of Done. A story is just completed when is fully localized. My experience shows that is difficult to include testing inside of the sprint. A possible way is to perform the testing within the next sprint when all the stories are done and fully integrated.

Resuming:

  • Strings are created by the responsible person
  • GUI personal needs to design the GUI taking into consideration other languages than English that will take 20-30% more space on average
  • Developers work directly with resources files
  • Localization department can localize the strings during the sprint
  • Localization department can create localization testing cases based on the GUI specs for the stories being implemented during that sprint
  • When the localization is ready, the resources files are included in the build
  • Localization testing is performed in the next sprint

As a result, at the end of the sprint we will have:

  • Software localized
  • Localization test cases created
  • Localization testing can start in the next sprint

This will help to reduce all the problems mentioned in the beginning of this post.

Do you think this is helpful?

Do you have any ideas?

Final3dPostCTA

11 thoughts on “Is Localization delaying your product release?”

  1. Lucian Adrian (@lucianadrian) says:

    First you say “Localization testing is performed in the next sprint”, and then “Software fully localized” at the end of the sprint. Fully localized does not mean that it is also tested ? Doesn’t this come in contradiction?

  2. Luis Goncalves says:

    You are completely right Lucian :) Thank you so much for your comment ;) I did correct that part on the blog… It will be localized but not fully localized, like you said fully localized would mean tested as well :) Once again thanks ;)

  3. Marko says:

    Yep, localization should be tested within the sprint as any other feature. But how about regression testing, should we automate localization test cases as well (after texts are validated by some local person)? Or is that the reason, that localization tests are run as last activity?

    1. HI Marko,

      Is extremely difficult to execute localization testing inside of the sprint, I mean for new features because until the last day of the sprint the team can still produce features; after that the product needs to be sent for localization testing, which usually takes around 1 week. This is the main issue to have localization testing out of the sprint.

  4. Yves Giroux says:

    You could add as an important point, the importance to have clear copy writing guidelines for the English source text. Besides the length that is on average longer with other languages, avoiding or taking into consideration plural and gender cases in other languages, as well as capitalization rules helps to weed out a good amount of bugs straight from the start, because faulty english source strings are often quite complicated to fix late in the development stages.

    1. Yeap I fully agree with you Yves and everything what you said is quite valid ;) I just didn’t want to go to deep ;) ;)

      Thanks,
      Luis

  5. Christine David says:

    Hi Luis
    thanks, your remarks are indeed helpfull. At least it summarizes the situation.
    Some comments
    “GUI personal needs to design the GUI taking into consideration other languages than English that will take 20-30% more space on average” -> The collaboration between development and localization has to be much deeper: interaction for the source language quality (in your case English, in my case different source languages), the localizer discover typos or terminology errors that a tester focusing on functionalities does generally not detect. The developer has to follow some rules to avoid localization errors (e.g. no concatenations).
    Test: In an ideal world the localization has to be tested before end of sprint
    In my company GUI localization is usually not delaying a release but there are other localization parts that are definitely delaying a release such as the localization of release and user documentations. User documentation is long to write and is delivered too late to localize on time. Moreover the volume is to hight to be able to localize in reasonable time.
    Do you have experience with this?

    1. Luis Goncalves says:

      Hi Christine :)

      Me and a couple of friends are writing this book: http://www.agile-localization.com. I believe we will cover many of the topics that you are talking, but if you want we can have a chat over skype what do you think?

      Thanks,
      Luis

  6. Agile or not, you have to force your developers to follow i18n guidelines. It’s wise to stay one iteration/sprint behind the development process, sometimes it’s even wiser to have your own, longer iterations (depending on the volume of translatable content produced by developers, length of the develoment cycle and other variables). It’s not really about agile methodology, it’s about your goal. You can produce great localized product, released few weeks after the main release (“waterfall” model), and keep your customers extremely happy (I have seen this, especially for very complex software suites). And you can release badly localized product fast. Again, i18n is the key.

    1. Luis Goncalves says:

      Hi, being a coach the word “force” is quite strong for me :) but yes I understand what you mean. About having your own goal, sorry I completely disagree, you should have a common goal and common vision, otherwise it will fail. Yes you can deliver later with good quality but if you can deliver sooner with the same quality why not? :). And another thing, if you do it inside of the iteration, your feedback time is reduced drastically giving time to correct any errors. With waterfall you find all the errors at the end and almost for sure the release will be delayed. Thanks for your comment.

      1. Wojciech Froelich (@DrAvalanche) says:

        Goal = common goal, no need to disagree :) The key phrase in your comment is *if you can deliver*. I have already mentioned some factors that should be considered, but I guess the main problem I have with the described scenario is oversimiplification of internationalization. It’s not only “taking into consideration other languages than English that will take 20-30% more space on average” (which may not even be valid for mobile projects with limitations coming from hardware).

        Agile localization? Yes, but well developed and successfully implemented best practices for internationalization first.

Leave a Reply

Your email address will not be published.

*

Subscribe to our mailing list

* indicates required Email Address * How did you find me Name