Resources for making US software work in South America

March 8, 2011 11:45 AM

Could you direct me towards information about what it takes to make a US software product available and work in countries like Mexico, Brazil, Argentina?

So my company wants to make a product available in Central and South America, and to start with we need to figure out how to deal with logistical issues like:
-translation
-collecting payment (both front end like Paypal and back end like what do we do about local taxes)
-csv file exportation when people use commas instead of decimals in numbers
-local helpdesk/call centers for support
-I am sure I am missing issues that I don't even know to think about yet

Are there any helpful resources you can point me to so I can learn more about these things and what other companies have done to make this work?

Websites, books, your own personal tips are all welcome. Assume I am starting from square one.

posted by rmless to computers & internet (10 answers total)

The term you are looking for is Localization (or internationalization but I always hear it as localization).
posted by bitdamaged at 12:01 PM on March 8, 2011

Translation meaning the software/dialogs/strings etc, or manuals/product specs etc ?

If it's the software, well, depends on the coders, language and platform (windows/linux/etc). The software keyword is resource localization (or sometimes i8n), and it is a tough bear. (Hey, at least you didn't mention anywhere that reads right to left, that always hurt my head)

For the other parts, companies I worked with always had either a regional rep (ie company employee), or partner/VAR/corporate entity that dealt with the local stuff and was a reseller of the software (and may or may not have provided the sales engineer/pre-sales and post-sale support, with higher issues coming to the company)
posted by k5.user at 12:04 PM on March 8, 2011

This is the most fun one of all:

Does your product present a EULA? If so, good luck getting it vetted by legal professionals who speak all the different languages you're interested and are versed in the laws of the various countries you're interested in marketing to. It's a nightmare.

My personal preference would be to forego the EULA entirely, but apparently that's not an option.

Also, every time you change any UI text at all, you have to send it out to whoever does your translations and wait for it to come back in every supported language, and then you realize that the space allotted to that string in English is too small for the Spanish text, so then what? Make the space bigger for every language? Make separate UI for each language with the controls all different sizes (this is how it's most commonly done)?

Then try and test it in every supported language so that you can catch the inevitable failure where your software tries to write to "C:\Program Files" which is actually named something else in German.
posted by tylerkaraszewski at 12:07 PM on March 8, 2011 [1 favorite]

k5- both probably, I think we'd start out with interface, manuals, website and then also translate the code if we need to. It's written in Ruby.
posted by rmless at 12:22 PM on March 8, 2011

Just kidding! it's in RealBasic.
Thanks for the EULA tip, tyler
posted by rmless at 12:23 PM on March 8, 2011

The term you are looking for is Localization (or internationalization but I always hear it as localization).

They're actually two separate steps. The first step is internationalization, in which you extract all of the strings from the entire program and place them into external resource files. You also set up all number formatting so that it uses the appropriate system locale settings to format the textual representations of numbers, dates, and currencies.

The next step is localization, in which you translate the program's UI (and error messages, maybe) into the target language.

Internationalization makes your program international; localization makes your program local. Since most programs start out local, internationalization is the first step.

Anyway, OP, I highly recommend that you hire a professional technical translation firm for your software's UI localization, and not somebody's cousin (or friend) who speaks the target language.

There are two reasons for this. First, your cousin, or friend, isn't really that good; and if they're a native speaker, they probably don't know all the technical terminology of a computer. Pithy technical translation is hard, and requires far more in terms of skill than simply knowing both languages.

Second, and far more importantly, your cousin/friend is going to drive your programmers fucking crazy sending them Word documents full of wingdings, and failing to return localization files in the program-readable format specified by the programmers. A professional technical translator is used to instructions like "Please prepare the translation in UTF-8 encoding, using the provided template for key-value string lookup". They'll also be able to handle format strings for interpolated text (e.g. "you have %d days of your activation period remaining"), which I promise your cousin/friend has never even heard of before.

Using friends or native speakers can result in literally days and weeks of work for the programmers as they massage text back into a usable format, and often introduces all sorts of errors as they mangle the language in their massaging. I've been there, and I've done that, and it would have been $1200 cheaper to pay the $1200 to translate our UI into Cantonese than to pay me to fight with ambiguously-formatted, wingding-filled, Windows-encoded Chinese text for a week. For the Korean translation, they paid the professionals, and I was done with the localization in about six hours.

As for how to actually achieve the internationalization effort... well, you'll need to talk to your programmers about that. They're the ones who'll have to do the work. But, the first step is almost invariably loading all UI text from external files. And the next step is almost always removing all hard-coded system file paths (even relative ones) and replacing them with paths pulled from the environment and system. This is more of a problem on Windows than anywhere else, honestly--on a unix system, it's /etc in both Spain and Arkansas.
posted by Netzapper at 2:05 PM on March 8, 2011

Yes I want to use a real tech translator and not a random person or (as the finance guys want) a cheapo crowd-sourcing experimental service.

These are very helpful answers, thank you
posted by rmless at 2:18 PM on March 8, 2011

Another thing to be aware of is that if you have any printing in your application, page proportions are going to be different in the rest of the world vs. the US standard paper size. (A4 vs. 8.5"x11")

If you don't have any printing or it's all text, you're probably golden.

So while you're internationalizing your UI resources, you might want to carve out some time to resize art assets for the page.
posted by fifteen schnitzengruben is my limit at 2:26 PM on March 8, 2011

It depends on what kind of software you are selling, but when you conduct business with other countries you fall under US export control laws. You might be restricted from selling something like military-grade cryptography to certain countries.

You may want to briefly look over some pages like Export Control Basics from the US Dept. of Commerce to see if anything could possibly be covered.
posted by meowzilla at 12:55 AM on March 9, 2011

To add to this, here's an askme from this morning where one very common problem with internationalization shows up. How to handle input in other encodings, and how 95% of every programmer will screw it up.
posted by k5.user at 7:14 AM on March 9, 2011