ELIA Networking Days Tuscany – in review

7097_1482923848648367_2417546588354282182_n

Another ELIA ND event is over – unfortunately – because it seems that all attendees would rather stay in the Tuscany area and relax with amazing food and wine under a gorgeous weather. But – returning to reality – we all have to get back to our regular lives and, of course, continue to run our localization business. Speaking of, let’s round up what we took back with us from this extraordinary event:

1. As mentioned before, dozens of (red) wine bottles that we are sure will help us relax after (or during?) our hard-days work.

2. Lots of interesting thoughts about our industry future:

  • During the “Wired/Tired/Expired” session by Michael Oettli, attendees were divided in teams and had to discuss and report back the trends/tools/processes in our industry that are obsolete (Expired), just barely making it (Tired) and are in for the future (Wired). We were surprised by the common ground reported back: Our industry is changing fast and LSPs need to adapt to new models, processes, technologies, but – most of all – attitudes towards client relationships.
  • In the “LSP-Client Collaboration as a Growth Startegy for LSP’s” session, David Kanek and Robert Etches talked about the importance of involving the client in the translation process and suggested that we should all embrace changes in our industry. They also mentioned how we can use crowd-sourcing to cut down costs and  pointed out that even banks have fans! Their main point: We sell solutions, not words!
  • During the “Perfect Tools” session, led by Christian Schwendy and Patrick Bajon, in addition to all the nice technology tweaks that all the teams reported they would like to see (including a client bank money extractor tool), we were introduced to the Six Hats theory that can prove very useful in our every day business. We will certainly put it into action in our company!
  • In the “Why is MT about speed” session, Eef Blommaart  pointed out that we can provide “Fast”, “Good” & “Cheap” services, all at the same time by using machine translation.

3. Some practical tips from sessions to apply to our daily businesses:

  • Robert Ganzerli presented tips and tricks for preparing a budget in our (uncertain) industry. Main points: Use historical data and involve everyone in the thought process.
  • Maria Kania-Tasjak advised us on which RFPs are made for loving and which we should avoid. Hint: Look carefully at the RFP questions – there lies the client’s problem!
  • Anne-Marie Colliander-Lind stressed out the importance of having a written social media strategy and showed us how far 100 euros can take you in social media marketing.
  • Henk Boxma presented an interesting case study regarding screenshot localization and described the solution he developed to generate one screenshot for all target languages simultaneously.

Last – but not least – the infamous Bull’s Eye session was definitely one of the best in this series. Manal Amin and Tea Diettrich created the ‘el clasico’; two totally contrasting in style presentations that attracted similar comments from panel and audience alike.

Commit has enjoyed the event thoroughly from start to end (including the wine which wasn’t actually ending) and is looking forward to be part of the next ND to be held in Lyon, April 16-17, 2015. See you all there!

10+1 tips to prepare your software for the world!

Oct-2014_header


by Effie Salourou, Customer Operations Manager at Commit

Many companies seek to localize their online, desktop or client-server products for the worldwide market. But due to lack of appropriate preparation and planning, many localization attempts are met with frustration once the software is built: the encoding doesn’t look right, the text is corrupted, sentences are cut off and in general, the software does not work as initially designed.

Here are some tips to help you avoid these problems, save time and money and produce a quality product for the global market.

1. Analyze the situation and plan ahead

Many companies do not think about software localization until the last minute before a product release. Scheduling and planning should be made well in advance and it should take into account all the necessary steps of the process: translation, review, testing and regression in order to deliver a quality product.

2. Externalize all translatable content

Taking the text out of the code and placing it in resource files is the first step towards a properly internationalized application. Separating the text to be localized from the code helps to avoid code duplication issues and also lets translators and engineers work on updates at the same time. Furthermore, it removes the possibility of damaging code during translation.

3. Invest in a style guide and glossary

The style guide defines the style, terminology and conventions from the beginning and provides uniformity in style and formatting throughout your software and documentation. It improves the quality of your translations, minimizes inconsistencies, adds professionalism to your work and saves time and money.

4. Understand translation tools

Learning more information about how translation tools work will help you take maximum advantage of this technology. Translation Memory is a tool that stores all translations into a database in real-time as the translator works. This database stores “segments”, which can be sentences, paragraphs or sentence-like units (headings, titles or elements in a list) that have previously been translated, in order to aid translators. These segments can be reused when the same segment is repeated elsewhere in the project, or in updates. These tools greatly diminish the time and cost of translation.

5. Provide room for text expansion

Translated text in most languages takes up to 30 percent more space than the English text. Leave enough room on your layout for expansion or program dynamic UI expansion into your software. If there are strings that cannot exceed a certain size, you should include comments in the resource file for those items.

6. Use Unicode/UTF-8 encoding of strings

Make sure to always source your string tables or software resources in Unicode/UTF-8 encoding. These character sets are created to enable support of any written language worldwide. Having just one way to process text reduces development and support costs, helps to avoid extra conversion steps, improves time-to-market, and allows for one single version of source code.

7. Avoid concatenation and overuse of single strings

Most languages do not follow the English syntax and word order. Concatenated strings and strings that are used in multiple contexts end up having awkward grammatical constructions and gender agreement issues.

Concatenation only works when content is written for a specific language. Now, when it comes to localization, concatenation makes it difficult – even impossible in certain cases.

8. Internationalize dates/numbers etc.

This step is very important because it enables dates, numbers, and other region-specific data to appear in a familiar way to users all around the world. Such data may differ even between regions that speak the same language. For example, while the US use MM/DD/YYYY for date, UK use DD/MM/YYYY.

When writing code, engineers should always keep in mind that countries might use different date and time formats, they might use a different calendar system, they might be in a time zone with partial-hour offset, they might use different currency, they might have different phone number formats and they might use a different measurement system.

9. Provide comments in software resources

The use of comments in software resources can be very helpful for translators because knowing the context and use of certain strings can help them choose the right translation from the beginning. Most translation tools will let translators see these comments while translating.

10. Localize help (UA) and software (UI) at the same time

Many non-English users around the world have noticed when Help or a User guide prompts them to click on a button that it is worded differently in the software itself. Try to localize the user’s manual, online help files and graphical user interface (GUI) at the same time to ensure consistency.

10 + 1. Test your software

Testing the software before its release is an integral step in the translation process. It should be performed by trained localization QA professionals and it will help to expose possible technical issues related to UI sizing, text truncation, hard-coded strings, character corruption and over- translation. This final step also gives the linguist the chance to actually see his translation in full context, often resulting in necessary changes to the translation.