Thanks for posting, James. Good point on the investment AND trust required from the project/vendor in their response to this grassroots globalization.

JL

Hi Dennis,

The concept of a “U.S.-based vendor” of software might be meaningless if you are in the US, but it means a huge amount if you are trying to get a business up and running in, for example, Eastern Europe. In that position would you rather feed off the scraps left by the dominant US vendors or try and build expertise based around open source software?

Some will choose the former - that is where the volume is after all, but others will choose the latter based on their ability to engage in the collaborative process and attempt to build a sustainable local economy. Those that choose the latter option are being actively supported by the EC and, in many countries, their national and regional government.

When software is tied to a vendor it does have a nationality in the eyes of many users. The fact that the code is open helps to break down the boundaries. In fact this is one of the few areas in which the open source development and distribution model does make a difference, in my opinion.

Hi Denis,

Thanks for posting. I think Matt summarizes pretty well the way I meant that traditional software and its vendors DO have nationality, particularly outside of their nation of origin. Open source, which is an enabler for local communities and businesses, does not have as much of a ‘country of origin’ since the code is developed and used by people all over the world, including in your town.

I’d also like to make the point that from a sheer economic/business perspective, a proprietary vendor must research and invest where in the world its greatest international opportunities are if it wants to grow a presence or revenue there. Open source vendors, by contrast, are told which international opportunities are greatest by their presence and participation and then given the option of following up on development and use in a particular locale, all for absolutely zero investment (other than making the code available as open source). It may sound too good to be true, but it is the effect of open source software development and distribution when it is working properly.

JL

Hello Bob,

Sorry for the delay in response, but I passed your query onto Fedora’s Paul Frields, with whom I discussed this topic recently. Here’s his detailed response. Thanks for the question, and thanks again to Paul for his input:

“The venerable but incredibly widely-used GNU gettext libraries provide
internationalization and localization (i18n and l10n) capabilities for
a wide variety of software:

http://www.gnu.org/software/gettext/

Originally written for C, they have since been ported to a wide
variety of other languages, including C++, Perl, Python, Ruby, OCaml,
and so forth. Programmers can use a simple syntax for marking strings
of text in programs, or use any of a number of utilities freely
available for detecting strings of text in regular markup such as
XML.

Since we write a lot of documentation in XML formats, and produce a
lot of code in languages that have gettext support, it’s very easy to
produce translatable content. The procedures for doing so are fairly
standard, and typically programmers simply use the conventions long
established in the open source community. By way of example, the vast
majority of programmers use a “_” marker to establish translatable
content in a number of languages and content dialects.”

Paul also writes about an example using Python, and refers to a tool for file distribution and translation:

“Not to get too technical, but for instance, in a Python program I
would have something like this:

= = = = =

import gettext
_ = lambda x: gettext.ldgettext(”anaconda”, x)

# … blah blah, more code here …
mymsg = _(’This string will be extracted for translation.’)
print mymsg
# … blah blah, more code here …

= = = = =

The gettext library transfers these strings into a specially formatted
file that can be distributed to translators or teams. The translators
can use any of a wide variety of tools to translate the strings of
text into their native language, and resubmit them to the project
developers for inclusion in the official release.

There are now also a number of tools that offer web-based distribution
of translation files, and/or web-based interfaces for actually doing
translation through a browser. One example is Transifex:

http://transifex.org/

The Fedora Project uses this specific capability to provide
translations for those codebases for which we are the upstream, such
as hosted projects originating with our contributors and our
distribution-specific system configuration tools.”