4 ms·

I think this highlights a problem. Localization _can_ be hard, but most of the time it's not. You shouldn't be scared to localize your app. After all, there's

by gnaffle 16y ago

I think this highlights a problem. Localization _can_ be hard, but most of the time it's not. You shouldn't be scared to localize your app. After all, there's a vast amount of open source software that has been localized with gettext without problems. In my experience, most translation strings are straightforward, and the corner cases as mentioned in the article don't happen very often. If you can tolerate a few hacks in your code, or a few extra translation messages, you don't have to go all the way down the rabbit hole. The perfect is the enemy of the good in this case.

joeyh 16y ago
In my experience, fully localizing a piece of software tends to lead to one of the most complex and fragile parts of its build system (especially if its documentation is localized too), often takes an appreciable amount of its total build time, tends to bloat its installation size by double or more, and leads to problems of inertia. The last inhibits eg, minor changes to a string, since any such change is making extra work for N translators (in my cases, N can be as high as 50). Also, it requires hard decisions, like should this language that has falled 20% out of date be disabled, or is it better for the program to startle the user with English 20% of the time? (Which 20%?) And finally, after all this work and pain, technical computer users will complain that they prefer the English version because their native language has clumsy terms for computing terms, or the translation to their native language is not idiomatic enough, or whatever. And you as the coordinator can't begin to judge translation quality unless you're fluent in N languages. I've been lucky to have very skilled people handling the translation coordination in some free software projects I've been involved in, and localization has still had most of these elements of pain in most of them. (Or if you prefer a proper rant: http://kitenet.net/~joey/blog/entry/on_localization_and_progress/ http://kitenet.net/~joey/blog/entry/on_localization_and_prog... )
- gnaffle 16y ago
  I agree that having translations adds inertia and resistance to change in the code, and that this can be a problem. You should add localizations when you "need" them and know that you are going to have to support them, not because they're nice to have. What I wanted to point out was that the article puts focus on a problem which often times is not that big of an issue. I've mostly been doing web development and localization of web applications, and I guess this makes the build process a bit simpler than what you describe.

by gnaffle 16y ago

joeyh 16y ago

In my experience, fully localizing a piece of software tends to lead to one of the most complex and fragile parts of its build system (especially if its documentation is localized too), often takes an appreciable amount of its total build time, tends to bloat its installation size by double or more, and leads to problems of inertia. The last inhibits eg, minor changes to a string, since any such change is making extra work for N translators (in my cases, N can be as high as 50). Also, it requires hard decisions, like should this language that has falled 20% out of date be disabled, or is it better for the program to startle the user with English 20% of the time? (Which 20%?) And finally, after all this work and pain, technical computer users will complain that they prefer the English version because their native language has clumsy terms for computing terms, or the translation to their native language is not idiomatic enough, or whatever. And you as the coordinator can't begin to judge translation quality unless you're fluent in N languages. I've been lucky to have very skilled people handling the translation coordination in some free software projects I've been involved in, and localization has still had most of these elements of pain in most of them. (Or if you prefer a proper rant: http://kitenet.net/~joey/blog/entry/on_localization_and_progress/ http://kitenet.net/~joey/blog/entry/on_localization_and_prog... )

gnaffle 16y ago
I agree that having translations adds inertia and resistance to change in the code, and that this can be a problem. You should add localizations when you "need" them and know that you are going to have to support them, not because they're nice to have. What I wanted to point out was that the article puts focus on a problem which often times is not that big of an issue. I've mostly been doing web development and localization of web applications, and I guess this makes the build process a bit simpler than what you describe.