A developer's guide to common mistakes and pitfalls made while working with localisers. Dwayne Bailey has worked across multiple open source and proprietary projects. Worked with multiple language teams. His war stories are told, not to shame, but to help you be effective when getting your product localised.

1. Some of my best friends are localisers
A developers guide
Dwayne Bailey, Translate

2. A little about me
✔ Started Translate.org.za - non-profit focused
on South African languages
✔ Translate - focused on assisting language
communities across the globe

3. What we do and why
●
We assist localisation teams
●
We assist companies
●
We develop tools
●
Essentially our tooling is community needs
expressed by localisers

4. Why this talk
●
We’ve bumped out head against developers
●
We’ve often had a different focus to
upstream
●
We’ve hit the same problems access
projects

5. Some history
●
Why can speak to this?
●
Localising South Africa
●
11 languages - think differently
●
Saw PO as useful
●
Built converters not because PO was great,
but because the tools where better
●
Pain * 11

6. This talks long term goals
●
Been threatening to do this for 11 years
●
Really to distil some of what we’ve know
●
See this as a workshop and we’ll make this
better over time

7. The Social

8. Lower the barrier to
participation
●
Technical skills mismatch
●
Web based localisation tools can help
●
Complex processes might help you but likely
don’t add any benefit to the localisers
●
You need some process, but be careful that
you aren’t designing out contributors
●
Nobody has complained
●
Try not to force localisers to be coders

9. Own team own goals
●
Yes, they’re part of your team and some only
do your software
●
But many are spread across multiple projects
●
They’re doing their language
●
Bad tooling? - they’ll work around it. We did
with oo2po, moz2po and Pootle
●
Bad process? - they’ll learn it, try fix, give up,
just live with it

10. Best localisers are your
localisers
●
They use your software
●
They care about what you do
●
Snake oil, or millions of localisers.

11. The Assumptions

12. Translators use tools
●
Introducing a new file format which matches
your projects needs won’t necessarily match
localisers needs.
●
Imagine being told that you can’t use vim,
you need to use emacs, or visa versa
●
Its kind of what you’re doing.
●
Yip you can do a quick localisation. But you
do lose things

13. Assumptions of language
●
The way your language works is not the way all
languages work
●
Marketing - be most careful if you are from
California
●
Idioms - it might be crucial to your software, don’t
assume everyone reads scoff or understand your
references to Faulty Towers
●
Tone/chatty/register - you can’t change it, but be
aware of it

14. Technical

15. Use a standard format
●
Either an accepted standard PO, XLIFF or
what is expected in your domain
properties, .ts, etc
●
A new file format means people can’t use
their tools

16. Variables
●
If only there was one variable style? We live with what upstream
language gives us
●
We’d all want to avoid the situation as in OpenOffice.org with 11 different styles
●
What do variables contain?
●
%d vs %s but then you need to be a programmer
●
Comments can help
●
Only variable info - don’t put your program name in a variable
●
Allow reordering - some languages need to reorder your variables.
●
%s %s doesn’t help here
●
%1 %2 does
●
Careful named variables
●
%(file)s -> %(leer)s

17. Split sentences
●
I am a good sentence.
●
“I am a “, “bad”, “ sentence”
●
Why? “I am a sentence that is “, “good”.

18. Punctuation and
capitalisation
●
Don’t assume that how your sentences work
works the same in other languages
●
sentence[sp]? in French
●
Name: [ ]
●
Capital N and colon are a convention that might
not work for some languages
●
Title Case is not common in most languages,
don’t force it to be built in

19. Terminology
●
Rasterisation and Posterisation - does
anyone know that that means
●
Your tool will have terminology
●
Office suite: format, justify, word processor
●
Audio: levels, balance, volume, track

20. Comments
●
The best people to add comments are localisers
- see if you can help them be able to do that
●
Too many comments are a pain when they
restate the obvious
●
Good comments enhance or explain what might
be confusing
●
All comments need to be parsed by the localiser

21. Context is everything
●
Don’t take away context
●
Don’t sort a list of strings

22. Plurals
●
We have them, let’s use them
●
They don’t work like yours
●
CLDR plurals “zero” and “one” don’t mean 0
and 1

23. i18n

24. Localisation from the start
●
Adding it later means you’ve baked in
badness
●
RTL from the start, mostly solved by
frameworks
●
Don’t assume layout goes LTR and you’e
almost there
●
Use UTF8, etc and you are almost there

25. Number and dates
●
While I’m comfortable with 1,000,000.00 I
actually want 1 000 000,00 and so do many
others.
●
6/10 6 November, 10 June? - it just makes
be feel foreign in your software

26. Names
●
Names don’t work like yours
●
Alaa and el Fattah - is my friends name, but
how exactly does he squeeze that into your
First name, Surname widgets? He hacks it,
but you made him feel foreign
●
Brand names are translated in some
languages.

27. Conclusion
●
Hopefully you’re not overwhelmed
●
Help me expand and clarify this list
●
Take away:
●
You have some information to help you be
better when you are localising
●
Not make assumptions about language
●
Listen and ask your localisers
●
We want to localise your software!

28. Baie dankie
Contact me:
Dwayne Bailey <dwayne@translate.org.za>