Apps optimize

Poll: What geographic size do you target when writing apps?

When you write applications, can the apps only be used locally, or are they useful globally? Let us know by taking this poll.

Development tools keep getting more options for multi-language and multi-culture support, and computing platforms (particularly mobile platforms) are becoming inexpensive enough that they are less rare even in developing nations. As a result, it is increasingly possible to write applications that are usable across the world. However, writing these applications is still a challenge.

I hate to admit it, but I don't take non-English speaking users into account with most of what I do, and I don't test on devices that are similar to what someone in another country might use (different language, keyboard settings, etc.). In general, I target a North American audience for things that I work on.

What about you? Are your apps local (city or maybe state/province)? Or perhaps they are useful in a larger region? Answer the poll question, and then share your feedback in the discussion.

J.Ja

About

Justin James is the Lead Architect for Conigent.

29 comments
Slayer_
Slayer_

Farther than that is difficult as the laws and language change. We don't even support Quebec cause they are primarily french.

oldbaritone
oldbaritone

I worked for a company several years ago who had a database application. They did a word-for-word translation into French, using translation software, to satisfy the Canadian bilingual requirement. It was a disaster. The translation was so poor that the francophones in Montreal used the software in English. (If you're Canadian, you understand how significant that is.) One example they told us was that the translation of "Commit", used in the context of "Commit this operation into the database", had been translated to a French word "Commit" with the connotation "Commit this person into an insane asylum". They told us the translation was so bad that it was funny - and unusable. Idiom is always a problem. Expressions like "hit the showers", "bite the bullet" or "kick the bucket" don't translate properly. Another somewhat-dated expression, "slick chick" becomes a major faux pas if translated into French; but "chou" in French becomes "cabbage" in English and loses its meaning. And these examples are all of English to Western European languages. The problem is even more difficult with languages outside the romance/germanic/teutonic groups. Syntax, culture and concepts share fewer common roots. Word-for-word translations are totally inadequate. Truly, the only way to translate properly is to hire a bilingual native linguist, and the good ones are pricey. When you project the cost of translation and maintenance of the translation as an ongoing expense, the numbers mount quickly. It's risky to translate without a hard sale, but it's difficult to make a sale without the translation. Spanish linguists are readily available in the US, and French linguists are available, but other translations can be challenging in all but the largest cities. Overseas sales also may mean overseas regulations for you, and of course the customer is dealing with an overseas company (you) from their perspective. It's difficult for any company but the very largest ones to justify multi-language translation - except for FOSS, where a native linguist will undertake the translation for free.

HGunter
HGunter

There are many of them to be found in other countries! If you want a translation into German, look in Germany, if into French, look in France, if into Urdu, look in India. You are guaranteed to find someone who is fluent in both English and the native tongue in every country, and they are very well placed to translate into the local idiom. Think outside the border ...

apotheon
apotheon like.author.displayName 1 Like

Then you have to deal with regulations on hiring non-citizens of your own country, tax problems, issues with sending money across borders, and so on. Government makes it very difficult for non-international organizations to deal internationally with employees. You're better off just using someone local or forgetting about it if you're a lone developer or involved in a small startup.

Sterling chip Camden
Sterling chip Camden

http://www.conveythis.com/translation.php It uses automated translation to a series of other languages and back to english to show how bad it can get. I tried: "Bad translator sure knows how to screw up a phrase." After 56 translations it was reduced to "Not doubt."

Slayer_
Slayer_

Purple monkey dishwasher It doesn't even end off in english

Jaqui
Jaqui

"I hate to admit it, but I don???t take non-English speaking users into account with most of what I do," Since the end of WWII US English has been the language for international business, in recognition of the impact the US had on the course of the war. While it isn't a daily use language for most people not in an English speaking country, it is also not uncommon in them. "and I don???t test on devices that are similar to what someone in another country might use (different language, keyboard settings, etc.)." um, unless you are taking direct control of the hardware with your app, shouldn't the underlying os handle those differences if your app has i18n built into it?

HGunter
HGunter like.author.displayName 1 Like

The ascendancy of English little, if anything, to do with American involvement in WWII, and much to do with the British Empire as was, along with the fact that it's grammatically simple and vowels are substantially irrelevant. The spelling is a pig, but not as bad as the "language of diplomacy", but the simple grammar is the biggie.

Sterling chip Camden
Sterling chip Camden

... the rise of the Internet, and its origins in the US. But that's changing...

HGunter
HGunter

English was the world language long before the Internet was in existence. French was agreed to be the language of diplomacy, but English became the language of commerce. A large part of the reason was the wide spread of the British Empire, upon which the sun never set for decades, which spread the language to large parts of Africa and Asia and Pacific islands - and North America, of course. Add in the fact that most of the world's knowledge is available in English, and you have a compelling reason for it to be taught in non-English-speaking countries. The Internet rode the back of that, if anything. Not that the history particularly matters - the fact of its pre-eminence is what's important.

apotheon
apotheon like.author.displayName 1 Like

Simple grammars, small token counts, and expressive semantics add up to a good language to learn. The same is true of both natural languages and programming languages.

Justin James
Justin James

Jaqui - Does your OS translate the documentation for you? If your application does, say, tax calculations, does it figure out the tax scenarios for other countries? Making an application work for other languages is about a lot more than number and date formatting... every time you compare an input to a string literal you are potentially having a problem with this kind of stuff that the OS can't handle for you. J.Ja

Jaqui
Jaqui

if I was doing a tax calculation app, I automatically look at making it work from an imported table of tax rate. The type of table that national revenue agencies [ the IRS and CRA ( Canada Revenue Agency ) ] make available specifically FOR such apps. and yeah, the documentation is the biggest hurdle for i18n, since the "scripted" translation tools do literal translation, which doesn't make sense to the native speaker of the languages. It takes man hours from people who know the language(s) to get documentation correct. I was thinking more setting the code up to enable using i18n strings depending on the language chosen by the user with my original post. If you set it up that way from the start, then it is far easier to ADD the i18n in if the client wants later on. if it's my own personal favorite type of project, free software / open source software, then it becomes an automatic requirement to support i18n from the start. That does colour my working model for development, but really, it's a beneficial impact. :D and, working with utf-8 character encoding makes charset recognition much easier, so comparing user input is simpler. have the app convert your english in utf-8 to hungarian in utf-8 for example, might not be a perfect match to user input, but close enough for the app to be able to continue functioning.

Justin James
Justin James

... but only because my business is a nights/weekend thing right now. I don't have enough steady work to justify making it my sole source of income, but if I did, I wouldn't need the contractors I have right now. J.Ja

apotheon
apotheon like.author.displayName 1 Like

Those are good reasons -- both of 'em.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

... why I never expanded my business to include employees. The other part is that I'm just an ornery bastard.

apotheon
apotheon

I look forward to seeing the results. Make sure you let me know when you write those articles.

Justin James
Justin James like.author.displayName like.author.displayName 2 Like

... I'm in the middle of this *exact* same conversation on Facebook, but in the context of another totally unrelated issue. One day soon, I mean to write a lengthy series of articles about some non-IT stuff. You might not realize it, but some of the conversations we had a few years ago played a large role in shaping my current opinions and beliefs. J.Ja

apotheon
apotheon

The sheer volume of business transactions that aren't conducted because of the time and expense involved in navigating incompatible tax codes and other onerous regulations is immeasurable.

Jaqui
Jaqui

it would almost be worth the effort to make the real working part a plugin and have the used plugin be chosen by the locale the user picks. so if they pick the US, then the federal tax info for the US is the only plugin loaded to do the calculations. if they pick Canada, then it's the one for Canada. though I'm sure that in the US you would also need state specific calculations also, I know we need Province / Territory specific here on top of the Federal.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

I feel qualified to say with great understatement that the tax rate is the least difficult part of it. It's all the rules for the application of those rates that cause the headaches. Those rules are generally complicated enough to keep a staff of developers busy year-round for each taxing authority supported -- never mind the interactions when multiple taxing authorities apply.

HGunter
HGunter

The choices you offer in your poll are: local, national, continental, global. What is not clear to me is what you mean by: - local (but I think you mean a US state or smaller zone) - national (but I think you mean the USA) - continental - the Americas, or Europe? The question as asked is really meaningless, though. Whatever the results the survey returns don't seem to me to be able to indicate anything useful, and I can't complete it because I don't know what information you're after - sorry. What matters is not the geographic region, but the language. English is the most widely-used language, but the most widely-used spelling of that language is British, not US, spelling (but so few US application-writers are aware of this). English is usable to a great extent in most countries of the world, but not usually used on a daily basis by the locals, so an app that restricts itself to English is reducing its market to a tiny fraction of what's available. Supporting other languages offers more challenges than just translation.

Justin James
Justin James

See my more detailed response to Jaqui below. Language is *not* the only thing that's important to many applications. As soon as money exchanges hands, anything involving laws, tax codes, etc. are concerned... language becomes an almost secondary issue. I *do* think that the explanatory paragraph before the poll should have been clearer, though, and for that I apologize! J.Ja

Sterling chip Camden
Sterling chip Camden

... date formats, weights and measures, character sets (a subset of language, granted, but a potentially difficult aspect of it), etc.

Sterling chip Camden
Sterling chip Camden

Seriously, though -- for some of my clients, their software I work on is marketed globally, so i18n is a requirement. Others may have only a national focus, or on rare occasions only a single location focus. I try to keep i18n options open in everything I develop, but it's such a PITA in most environments that it sometimes slips when it isn't required.

Jaqui
Jaqui

Yup, i18n is a p.i.t.a. specially if your knowledge of other human languages is limited. but even if you only make sure that it's set up to enable it in the future if the client decides it's needed, it's well worth the effort to do. basic ui translations, you can get a good database of them so you can have the app work in multiple languages easily enough, over time. The failure of most i18n work is in the the documentation. hard to have all the help system translated into grammatically and syntactically correct $LANGUAGE if you aren't fluent in it. Read some of the English docs for a lot of open source software, you can tell they were written by someone who isn't a native English speaker because the grammar and syntax aren't correct. Most people might let that slide, saying to themselves that at least the software HAS something for documentation that I can use. I myself would prefer to ensure that the documentation is correct for all supported languages though. It makes the development team look more ... professional, if they make that effort.

Realvdude
Realvdude

My sphere doesn't extend much beyond the state I live in, though I hope my world is a little bigger than that. It's a good thing to think about when considering any endeavor. I can see it now, Rat Cather available in 12 languages.