Localization
now browsing by category
How to use crowd sourcing for localization validation/testing
Hi guys, several weeks ago, as some of you already know, me, Vasco and Wim started this project: www.agile-localization.com. During this time we have been taking notes and thinking about several topics that we want to talk tackle in the book. After collecting all topics, we realised that we could write a pocket book in parallel with several “How to´s”. This small pocket book could attract readers that are not interested in a full story of the original book, but instead, they want practical exercises to implement within their teams/products. This is the result. Below I want to share the first “How to” and I would like to get your feedback. Your feedback would be important for me to improve and write a final text.
How to use crowd sourcing for validation/testing
Several years ago one of the authors worked in a big mobile manufacture company as a Localization Manager. He was responsible for localizing several products within the organization. These products were delivered to millions of users all over the world, so the localization quality was extremely important for the company in order to keep a good brand image. Imagine yourself buying a phone and when you start using it you barely can understand the translations. Most probably, you will not get the best image of that company. This was happening not only with customers but also with employees. They were not happy with translation quality delivered by vendors.
In the beginning, the author thought this was normal situation. The problem is that people in the team were too involved with the product and they were familiar with product features, therefore it was easy for them to be unhappy with translations provided by vendors. However, the situation started to be too annoying due to repeating complaints of translations. Everyone started to think that the organization couldn´t afford to ship products with such a poor quality level. Adding more testing would not help much, because based on experience, the author thinks that increasing testing will not improve the linguistic quality that much. So, what would be a possible solution for this?
How about if the company would use crowd sourcing to help the validation of the product? This is exactly what they did, so let´s see how it was done:
1) The author started to take screen shoots of the most important products screens. The screen shots were taken in English in order to compare the English version with the one they would have on their own devices.
2) A survey was created with a question for each different screen shot asking: “Do you agree with the current translation?” a)Yes b) No. If No, please can you provide the correct translation.
3) The survey was spread inside of Beta Community and within the company
4) A script was created to analyse all answers
5) All translations with an acceptance below 95% were written on “Improvement List”
6) An avg translation score was calculated to measure how accurate the translations were for each language
7) For each word on the “Improvement List”, the top three suggestions were collected
8) All words within the “Improved list” and their respective suggestions for improvement were sent to the marketing department in order to select a final translation
9) The changes were implemented into the product
10) The survey ran again
11) All metrics were calculated repeatedly
12) The quality was improved drastically
This is an example how crowd sourcing can help companies to increase a product quality.
What do you think? Do you think its useful or not really? Please leave me your comments :)
Is there any demand for “Agile Localization”?
Hi guys, this week I want to tell you what I have been up to for the past couple of weeks. I have written about it as it is always easier to see new ideas in a better light once they are written down. The purpose of this particular post is to invite you to a discussion about Agile Localization.
I have previously mentioned that I started with Agile some years ago, around 2007. Few years onwards while working for one of my previous employers I became responsible for improving the localization process for several products. At the time the localization for those products was done the traditional way - at the end of the product development process towards the end of the project. My role here was to change the traditional approach in-line with the Agile approach so that the product deliverables of each iteration would be localized. The initiative was a success and we were able to have product deliverables of each iteration localized in 87 different languages. After some years of working with Agile I decided to share all the knowledge I acquired during those years with other Agile developers out there, so I started the “Agile Localization” project.
I started writing a book on the subject thinking that it would be something I do in my spare time, but feedback I received from several friends and colleagues made me believe that my interest in Agile localization could lead to something more than just a book. Such as, a consultant might consider writing a book in order to have a successful career in consultancy. Together with two other colleagues we started a consulting company “Oikosofy”. The website mentions several innovation and Agile services that we offer, but there isn’t a mention of Agile localization there.
However, I think Oikosofy could offer Agile localization as a service to localization vendors to be offered to their customers. At least this is what I had in mind when I had a “sales call” from one of the vendors. But it seems the guy did not understand me, rather, as one of my business partners puts it: the problem is not with the listener but with the messenger. I believe, I did not explain myself well enough. So, I take this opportunity to explain my idea in order to see how you like it. Let’s say in this post I present my MVP(Minimal Viable Product) and I would like your opinion on whether there is a demand for this service out there.
The idea behind this service is to help companies sync their localization with their Agile development, so that the deliverables for each iteration would be localized. Of course, to make this possible a team must be already working in Agile and if they are not working in Agile yet, they can always contact us for help with the transition to Agile :). But coming back to the topic, this would be a service designed for teams that are working already in Agile yet still treat localization as something to be done outside the Agile process, at the end of the entire product development process. So our role would be to coach the team while working together with them and helping them adopt Agile localization practices so that they could have their product deliverables localised for each iteration.
This service would be offered as a partnership with the localization vendors who would take care of the localization of the product and we would be working together with the customer changing their way of doing localization. This would help the localization vendors because it would improve their collaboration with the customers taking it to a new level. Instead of receiving a huge amount of strings at the end of a development project they would be able to deliver small batches of translated strings for each iteration. This would be also beneficial for the customer because it would allow the customer to have the deliverables of each iteration in all the languages they require. Another advantage here is that the feedback loop would be scaled down, too, which means the customer together with the localization vendor can timely fix any problems with the localization thus improving the quality of the product and reducing its time to market.
So this would be one of the Oikosofy services in a nutshell - Agile Localization :). This is my idea of how Agile localisation could be developed into a service and I would greatly appreciate your feedback. Do you think there is a need for such service? Do you think Localization deserves to be a special service for Agile development, what would be pros and cons of it?
Thank you so much for your most valuable input that will help us a lot in developing further the Agile community!
Agile Localization - Outplay the competition, enter new markets and grow Internationally
Hi guys! This will be my last post this year due to Christmas season. I would like to take this opportunity to present my new personal project. Together with my two colleagues, Vasco and Wim, we are going to write a book about Agile and localization. The general overview of the book can be found here.
The people who know me understand that I am very passionate about Agile. So, we would like to take an Agile approach in writing our book. It will remain to see if this experiment would be successful, but since I have this idea, I would like to try it out. Put simply, writing a book is a creative process much like developing software - at the end of the process there are potential customers that would buy the final product. Therefore, why shouldn’t we write a book applying the methodology we use to develop a software product?
Our idea is simple. Like in Agile software development, we are planning to write the book in iterations, which means that we would not follow the traditional pattern: first write the whole book, then publish it and only then get the feedback. Instead, by the end of each such writing iteration we want to release the increment of the book we wrote and get the feedback from the public. Like in Agile software development, the feedback will be integrated into the book to improve it. Every time before starting a new chapter, we will communicate its topic to our audience and invite our followers to a discussion about what they think is important to include in the book. Naturally, the book will have the main story, but the idea is to adapt the book to our “readers´ needs”.
The localization of the book will also be part of this incremental process. To have the book localized for a particular market, we would not need to wait for weeks until the product would be released in English first. Instead, as soon as the iteration is finished, the released increment of the book will see the light in English and in some other languages, too. If we really believe in this concept, there isn’t a better way to prove it than to apply it in our own book.
We are starting this project in January, and we would highly appreciate all the feedback from you, guys. If you are interested in our project, let us know! Let’s use this blog for communicating and collecting your thoughts about the book. Another thing, we would highly appreciate if you could tell us how much you are prepared to pay for the final product – the finished book. This would give us an idea about the price range for price-tagging the book, please, leave your comments here. Another way to leave your comments will be using our NPS system. Some weeks ago I wrote about NPS, you can find the post here. Before we start releasing the first chapters we will have in place a system where you can leave your NPS score.
There are a number of other issues that we still have to solve, but being truly Agile means that we will be adapting along the way and tackling issues as they arise.
Now, the only thing missing is your initial feedback. What do you think about all this, guys? Do you think this could be a cool project to be part of? Would you like to take part of this project?
Look forward to your comments ;)
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?
Localization
Being the localization manager for Nokia Maps in Berlin for the last 2 years I wanted to start this Blog explaining what Localization is. I will use my Masters Thesis introduction do describe it :) :).
“The biggest mistake is for people to think that localization is just taking a product and translating it” (Kubo: 2005). Localization is in fact more than that; localization involves more than just translation. Software localization is all the process of adapting software to certain culture and language.
There are several details to take into account. Some of the most common “issues” that need to be taken into consideration are date format, currency, addressee’s format, colours, graphics, etc. Colours and graphics are quite important but sometimes companies do not give too much importance to these aspects like they should; as an example in western countries red means alarm, white is pure, black means sombreness, for other hand in Asian cultures, red is joy, white express mourning and black represents luck (Collins:2001).
When a product is created, the localization part needs to be taken into consideration; otherwise the costs will be quite high. If the product will be sold in other countries these activities need to be well thought beforehand. (Downey: 2004). This is the reason why the first step for effective localization is to do the internationalization part.
Percy (2010) defines internationalization as the process of creating software that can be easily adapted to other countries. Localizing software that was not internationalized can be a difficult task. There are several issues that can make the localization part difficult if not well planned. Just an example, Arabic and Hebrew languages are different than western languages; these languages are called right to left languages, this means the reader starts to read from right to left instead of left to right like in western languages. In a software implementation point of view this means that all the software architecture needs to handle this. Another example could be the size of Japanese or Hindi characters; normal western characters use one byte of memory, but in order to localise the application in Japanese or Hindi, the application needs to support two bytes for each character. These are small examples to illustrate how costly it can be when localization is not well planned in the beginning of the development.
Internationalization should not be treated as a feature. Internationalization should be part of the product architecture. Engineering team should be deeply involved with localization team to make sure that all technical decisions will not have any impact when there is a need to adapt the product to other cultures or countries. If internationalization is treated as just a feature, it means its priority can be negotiated, with possibility to make the priority low. On the other hand, if internationalization is part of the architecture, it means that will define how products are designed and built. (Kuba 2005)
Please comment and give me your feedback about this :)
D5 Creation