Sorry if I'm chiming in too late, but having the locale as the first part of URL makes linking between language versions more difficult, because they should use absolute links starting with /.

If you had an option for locale extension, e.g. q-and-a-fetch-msg.locale.tcl instead of /locale/bboard/q-and-a-fetch-msg.tcl, then one could use relative links between same content in different languages.

Explicitely linking to another language is at least possible by specifying an absolute url like this: /ru/bboard/q-and-a-fetch-msg.

It should be easy to construct a language-switch page that redirects to the page it was referenced from with a different language prefix, possibly making it unnecessary to do relative links between different languages.

Some random questions / remarks:

Are you planning to enable both language _or_ locale information in the smart url system, e.g. by supporting both the urls /en/bboard/foo and /en-gb/bboard/foo? (I hope this is the correct distinction between the meaning of the words language and locale)

If yes then I'd like to vote for the /en-gb/ syntax instead of the more common /en_GB/, just for aesthetic reasons and in order to conform with the URL style of the rest of openacs.

When working on acs-lang, did you base your work on gp-lang from greenpeace, and if yes did you consider splitting the key into two separate fields in the database? As far as I remember the new style message keys introduced in gp-lang have always two parts, and it occured to me that having two separate fields would make a lot of operations on the messages easier (this is purely theoretical though).

Apologies as I'm not all that familiar with this whole effort but...

Increasingly its looking like I may need to be.....

Is therea description/doc or anything describing whats already there and in particular what was done for GP?

Thanks

Simon, check out Carl's Wimpy Point presentation at: http://openacs.org/wp/display/326/, and in there the case study.

The smart url detector should first see if it matches a pattern and if yes, see if that pattern actually contains an active language of the system, and only remove it from the URL in that case. So if /ds/ does not correspond to a real language that is also activated on the system then there shouldn't be a problem.

So this might still be a cause for confusion but not as serious as if it would be when all top-level two-letter URL's were disabled.

Steffen,

Yes, I've thought about something like that, but it's ugly! :)

I don't know what the best solution is here.

/locale=en_US/foobar? ... we can have an equal sign be part of the URL, no?

/Lars

We have committed our changes so far to the acs-lang package and the changes that we have made to OpenACS core. The CVS commit comment for acs-lang was:

adding namespaces to the TCL API, adding new procedures for extracting keys from adp pages and parsing keys embedded in text, adding a translation web UI that was used at Greenpeace (at www/admin) and making it work with PostgreSQL, moving the old pages under www to be under www/admin/test, making the lang_messages table use locale rather than language, added upgrade scripts

The most important changes to OpenACS core include substituting MESSAGE KEY MISSING: 'package_key.message_key' occurencies in adp pages with message lookups and setting up ad_conn locale in the request processor.

We are now working on committing Jeff Davis's magic script that can suck out translatable text from adp pages and replace them with message catalog lookups (yes I know, it's amazing, but it works!). As soon as we have committed this script we will encourage package owners to run those scripts on their packages and then test and go through pages and manually do any missing message lookups. We have started writing an I18N developers guide and you can find a snapshot of it here.