Technical

Using Multiple Languages

1. Without Machine Translation

Many Web sites and other software already work in multiple languages. For example, in Macintosh OSX 10.5 you have a choice of 18 languages in which system prompts will appear (under the "International" system preferences), and some applications will also use the language you select. This works well without machine translation, because the universe of commands required to run the operating system is fairly small and unambiguous.

Some considerations in applying this to RepliCounts:

First, a "public account" in RepliCounts is likely to be used by many people around the world, sometimes simultaneously. Therefore, it should not remember its current language setting. The language needs to be remembered for each use of the account. A handy way of doing this would is to use conventional short abbreviations for languages, such as en (English), es (Spanish), or zh-Hans (Simplified Chinese) -- right in the smart URL, replacing the www.

For example, under the Artists tab on this website, we used an example of a clickable public account: www.automatic-accounts.com/OurBand/OurSong. Anyone can click on such a link (a smart URL) to get a free copy of the song, video, report, or other content it delivers, provided that any paid sponsorships are currently available in that RepliCount. Then, to convert this link to work in French, for example, just replace the 'www' with 'fr', getting fr.automatic-accounts.com/OurBand/OurSong. End users might do this simply by clicking a French flag or other link at the account's public control center.

The new link still goes to the same RepliCount; the server processing this account has access to the language prefix, so it can set the language to French for this particular transaction (and to any future transactions caused by clicking on the new URL with the 'fr'). Users will then see French phrases for the limited set of standard meanings that a sponsor or end user needs to operate the RepliCounts system -- meanings like "click here for free download", "click here to sponsor bulk copies", "shopping cart" (within the "sponsor" page), etc. The "www" could simply default to whatever language the RepliCounts system was written in -- so that a simplified RepliCounts system (perhaps for testing) could use only one language, and ignore the issue entirely.

Probably about 100 meanings in the language table would be enough for people to navigate the RepliCounts system: doing free downloads, sponsorships, credit-card payments, uploading art when creating a RepliCount to deliver it, printing basic accounting reports with proper labels, etc. More meanings could be added to cover other specialized uses of RepliCounts (such as fundraising), which need not be supported by all RepliCounts servers. The server will need a table giving all these supported meanings in all the supported languages. Note that this way of using just one account for all the supported languages, and specifying the current language in the smart URL (Web link) itself, means that copies of the link set to any supported language can now be shared within a country (within a single language group), with no attention to language until one of the users needs to change the it again, in order to send the Smart URL to someone who speaks a different language. The clickable flags in the public control center should always be visible there, to let anybody change the language very easily.

Note that error and other messages from shopping-cart or other bankcard software will not need to be translated, since sponsors and others who are making payments to a RepliCount can be directed to a shopping cart in their own language.

Technical: We should mention that allowing multiple access to the same account, using either the same or different languages, will be considerably easier to implement in software than it may seem -- since the big problem of multiple transactions changing the same database record simultaneously can largely be sidestepped. Multiple simultaneous accesses will only be allowed for public accounts -- that is, for the greatly simplified control center (dashboard) provided for public use. Public users will be able to make very limited changes -- for example, to decrement the count of free downloads remaining within a certain sponsorship (by obtaining a free download), or to create a new sponsorship when paying for it. In each case, the RepliCounts record will be locked against changes for the microsecond or so required to subtract 1 from the free-copy count, or for the millisecond at most required to write out the new sponsorship record, after it has been created. No other transaction will need to wait very long in the queue.

Meanwhile, the other RepliCounts (that are not public accounts) will be used very differently; they will only be changed by the owner, or an authorized agent of the owner. Therefore there is no need to allow simultaneous transactions at all for these accounts.

A little programming thought will be needed to allow the owner of a public account to go in through the back door and make changes, while the account is live in public use. At worst, the public could be locked out when the owner is making changes. But this may not be necessary, because there will be so few changes that the public is allowed to make to these accounts. It should not be hard to avoid conflicts where changes are partially made, then erroneously overwritten.

2. With Machine Translation

Sometimes the method above for supporting multiple languages will be impossible or clearly unsuitable. For example, to allow multi-language access to a sponsor's personal message would require the sponsor to get translations of his or her message into all supported languages that sponsor chooses to provide. And for content, while songs seldom need translation, someone providing, say, investigative news reporting could hardly be expected to get it translated into a dozen or so languages.

For these purposes machine translation is needed. Fortunately, the field seems to be advancing rapidly at this time. Google has developed its own new statistical machine translation (see FAQ), now available as Google Translate, which already seems to work at least as well as the classical rule-based translation (available in Yahoo! Babel Fish, for example) -- even though Google's system is at a much earlier stage of development. Google Translate has largely caught on in the technical world. In seconds you can translate any page of this site into more than 30 different languages, just by using the Google Translate box near the upper right of each page.

Our question now is how to write content in ways to help Google Translate do the best job. We are looking for a simple set of rules for the writer -- and also for some way to enter a table of translated words and phrases for key concepts in a technical field that Google Translate may not yet be familiar with. If you have information on these questions, please let us know.

Other

This section is a work in progress. The page below is mainly text removed from other pages on this site. We will organize it better in the future.

[Advanced: a subtle point here is that though the name of a RepliCount looks like a URL, and sometimes is called a smart URL that can even can be clicked and then acts like a URL, it is not really a URL. Instead, we just borrowed the standard URL format for RepliCounts because so much Web software, email software, etc. is familiar with that format, and knows how to pass it along without choking on it, such as getting confused by certain special characters it may contain. In the example we develop below, only the www.server.com part is a real URL; the rest of the name is simply copied and used as data by the RepliCounts site. What looks like a directory structure in the name might sometimes correspond to a real directory, but usually it will not. And in the case of a language code, like en.server.com... or es.server.com..., it just comes in as a field to tell the account which supported language to use when it instructs the user on how to enter payments, how many free copies are available, how much it costs to sponsor N copies, or the few other instructions for using this system that have been entered at the server in every supported language. In case the language code is invalid, the server will give the user an error message in every supported language, plus the correct code for that language. Note that while RepliCounts will probably use the same two-letter codes, this is different from Wikipedia, for example -- where the English, Spanish, and other language codes take users to different encyclopedias for each different language. A RepliCount smart URL en.server.com... or es.server.com... is the same account, delivering the same art, and holding the same sponsorships -- allowing users to change the language at will, and distribute the smart URL that way among friends who speak the same language, but anyone can change it when a copy crosses a language barrier again.]

Re Spam Control

For selling art online, we highlighted "public accounts" (accounts irrevocably restricted so that they can never give any money out, allowing these accounts to be widely shared). But in our spam-control example, the concept of public accounts does not appear at all. Instead, the RepliCounts used can pay money, but are restricted in other ways, such as only paying for email, and having too little money in them to be worth stealing. So these accounts can also be emailed conveniently, without encryption.

Also, in the first example, the RepliCounts appeared in the form of a clickable URL; in the email example, a RepliCount was an 8-digit number (in a more general context, an identification of the server would be required as well -- perhaps a 3-letter combination could be used).

Many More Uses

What we have seen so far is just a sample of a huge range of new approaches to solving common problems, made feasible or at least much easier by reproducing accounts. These new methods will not solve the problems we face, but can be helpful when used together with more familiar and conventional approaches. For example, the mass sponsorship we propose will not save newspapers, but could provide an income stream by funding some investigative reporting delivered online. One possible business model here might be to find investors for a particular investigative article; the investors could put up the early money and profit if the story is a hit (getting possibly millions of video viewings, say, free to end users only when sponsors who appreciated the story had paid, say, 10 cents per view). The sponsors could give the access they fund to any of thousands of different audiences the sponsors want to support -- or want to reach, and deliver their personal, cause, advertising, or whatever message to the chosen audiences. Or sponsors just interested in the story could release the prepaid copies they buy to anyone interested. If people have problems finding free downloads or views, then that's an incentive to find more sponsors who can buy hundreds or any number of copies in bulk. And it's also an incentive for potential sponsors to instantly turn on public access all over the world (or anywhere they choose), playing the hero and saving the day for the important story and for many interested readers, either anonymously and perhaps in support of a cause, or otherwise.

All this becomes possible because each new account can inherit services of almost any complexity, instantly and effortlessly. Family trees of accounts can grow over generations. Professionals and other experts can program the features -- but anybody can change their work (in most cases), or do similar setup. The accounts and features that prove useful will tend to become popular, and also provide a new basis for further changes -- allowing grassroots control of these financial instruments, which can provide endless other services as well, in an environment where financial infrastructure is always conveniently available for use.

The RepliCounts as we propose them will not contain computer code (a helpful barrier against malware), so they will not distribute software. Instead, along with data, they will distribute settings that basically choreograph hundreds of routines that already exist on the server that manages the accounts. The software can be changed only by the company that manages the server, which (for security purposes) might not allow remote programming at all. But the very flexible inheritance of potentially hundreds of services and settings (many of which will be unused for any particular account) does provide a platform for distribution of computer services. And new routines can be developed and added to the server at any time -- even added to accounts that are "live" in public use.

An important advantage of distributing computer service through accounts instead of through operating systems or browsers is that the accounts already know about money, such as how to accept various forms of payment in various major languages, how to apportion transactions among different payees, how to keep accounting information and prepare standard or other reports on demand, how to communicate with account owners by email or phone when necessary, how to arrange for the mailing of paper checks, how to charge for such services, and much more. Financial transactions and other functions can be automatic in many cases, based on options that account owners have chosen, or have allowed to be chosen for them by default -- avoiding much of the need to stop the process and do something different once money is involved, like having people reaching for credit cards or filling out forms online. Instead, people moved by a song or a cause can support it immediately, while the song still plays. Sending email for doing so is described above, but there are easier ways.

Page updated 2009-09-30