Forum OpenACS Q&A: Community Bid: Support for localized .adp's

Internationalization is crucial for the success of the toolkit. One aspect is the possibility for translations of the toolkit and different design depending on the users locale. Therefore we would like to see the support for localized adp's.
  • A user shall have the possibility to choose his supported locales in the user profile. If he chooses for the first time, take the values from the browser as already selected defaults. Give them a clear ranking.
  • There is a locale table which maps locale code with something nice for the user to choose from {for the list above} (though de_DE is okay, I'd prefer German(Germany)).
  • Request processor needs to be amended. Based on the users preferences it serves the localized adp with the highest ranking (e.g. if I say I want German(Germany), French(Swiss), English in that order, the RP should serve me (in that order) index_de_DE.adp, index_de.adp, index_fr_CH.adp, index_fr.adp, index_en.adp, index.adp). Same is true for .tcl files, btw.
S&R would be willing to finance this work with $400 with a deadline on 15th of August. If this can't be met, the amount falls to $250.
Posted by Jun Yamog on
Hi Malte,

Why not just use cr_items.locale?  Instead of dispatching index_de.adp, etc.  Why not just use one index.adp and db get the correct content item  from CR?

I have got a good idea on how to make all packages CMS capable.  I have discussed it with DaveB it seems to be an ok idea.  Now that we need to support many languages.  Why not just use one index.adp and one index.tcl and have the different text/content on the db?

It would probably put the load on the db rather than aolserver if you use request processor.  But the overall design should be better in the long run as all content is now in db, logic in tcl and layout in adp.  Do you think this is a better design overall?

Hi Jun,

how would you support different layouts for different locales. From my understanding, we use the .adp to provide the layout. The easiest example which comes into my mind is the layout of tables for languages that are read right to left. The table needs to have the columns in the opposite order.

Furthermore, I am STRONGLY against storing more stuff than necessary on the database. The database is the bottleneck of all installations, especially as clustering a database is PITA. Whereas having more files on the aolserver filessystem spreaded across multiple servers does not provide that much trouble in comparison. Particularily if we talk enterprise we should think about scalable. And having 40000 students of a university access the system with one database beeing hit for every page a couple of times........

Posted by Jun Yamog on
You have a valid point, and I agree with your point.  Do we really need many adp and may tcl?  Why not just many adp and 1 tcl?  Of course we will need to clean up all .tcl which we should do anyway.  The tcl then will dispatch explicitly the right adp by ad_returntemplate.

What is the difference between de_DE.adp and de.adp, fr_CH.adp and fr.adp?  Sorry I have little background in locales?

Why not just give the $400 to DonB he is going to do it anyway atleast he gets to earn a little.

Hi Jun,

if Don does it anyway, he is happy to grab the money. But maybe other companies are willing to put money into this effort as well so he gets a little bit more for his efforts. And as you might have seen, we need it more urgent than he'd have the time to do it.

The difference between de_DE.adp and de.adp is that the Former is for the Germany German version of the .adp, while the de.adp is just German. Though this might mostly concern content, wording is sometimes different between e.g. Swiss german (de_CH), German german (de_DE) and Bavarian German (de_BEER ?, local dialect spoken in the southern part of Germany). And de.adp would be just German, probably using German german, but who knows. Same is true for French, or British, American and Aussie.

I would like to point the need of attention for languages like Greek
that are a bit different. I'm working on a Greek implementation of openAcs and I meet a lot of problems since I need to have both Greek and English pages. One more thing is that Open FTS is not working with Greek (or I cannot make it work).
Posted by Dan Wickstrom on
I'm sure Neophytos has looked at this problem before.  A long time ago , he mentioned something to me about some problems with the flex parser and problems with getting it to work with the greek locale.  I'm not sure if he ever got it worked out, but you might want to write him directly.
Posted by Don Baccus on
While I support the idea of funding projects like this, I'd like to discourage funding this *particular* item because it is crucial it be done right, and done in the core.

And it is very non-trivial to design it in right.

I'm not plumping for the money (though I appreciate Jun's comment) but but think we need to move forward in an organized way.  The main problem I have with your proposal is that it suggests it's a simple task which can easily be slid into the toolkit.  It's the timeline more than the amount of money that bothers me.  Reaching some level of  community consensus on a design by August 15th seems reasonable but not implementation.

Page layouts don't necessarily need to change with a right-to-left language.  Depends on the layout.  Then again layout may need to change for other reasons.  I would look at this as being a separate issue from localization.

I have a rough draft of an explanation of the approach taken in Greenpeace Planet that I can try to finish up soon and post for folks to look at.  I think our approach can form the basis for doing internationalization, as I mentioned at our mini-conference.

Hi Don,

my reasoning for the funding was that I assumed it had already been done at least within Greenpeace therefore we have an already decent design.

Seeing this flaw now I'll rest the bid for now til we found a design the community can agree upon. But I still think this is important work which might not necessarily be done within a clients project, so our intention for sponsoring the implementation is still there.

Sorry for the wrong assumption and the confusion this might have led to.

Posted by Jun Yamog on
I guess the expriment ended up pretty much the same.  The same thing happened on OACS rpm.

Lets take step back.  We all want to move the toolkit forward.  But we also want to move it properly.  Why not have the sponsoring company do some real hard specs.  Submit to community... rehash until the design is acceptable.  During this phase, for us to collaborate effectively we will need to make good documentation.  Then we just bid the implementors.

That way we can already make the docs, design, use cases, etc. prior to implementation, which normally takes a back seat once its implemented.  Maybe this way things will be more documented and better.

Or maybe what we need is to have the concerned parties work together openly.  Like S&R will surely need this feature so they open up their development and see if people or other companies will contribute.  The finished code may or not be accepted on OACS tree.

I really don't exactly know what will work.  Malte maybe rethink on how you would like to do this again.  The goal of a company maybe different from the goal of the community.  That is why we have the problem of code not being returned back because company have deadlines.  Company code and/or design are more crappy than OSS code in general.

But I think what you are doing may have some value to it.  Maybe it just needs to be rethink.  Please try again and who knows it might work the next time.

Hi Jun,

the idea with the deadline was bad. Agreed. Reasoning was just that universities could adopt dotLRN for their courses and have their students translate some pages, therefore getting localized versions as an immediate benefit. But as I said, bad idea.

A quick note on the company thing you mentioned. The system is in no way intended to get work done we need as a company. It is intended to reflect our willingness to put ressources into something we believe is valueable for the community, but we don't have the time and development power to do it on our own. If it were crucial to our success as a company we'd either be paid for it by a client or try to hire someone full time / full rate to do it.

But maybe we should have started with "I would like to see this in the toolkit, let's discuss how this can be done and once we have a solution, let's bid for it {or wait till someone does it and donate money to him afterwards}". Open for any suggestions, even "forget about it / let it rest / won't work". I've never done this before or seen something like this done, so it is a first time experience.

Posted by Tom Mizukami on
Malte - I think this is a great idea just maybe just not for key pieces that need to be in the core. Just because this might not work for this specific piece of the toolkit I hope this idea does not go away.
Posted by Don Baccus on
Yeah, Tom ...

I appreciate your willingness to put a little cash on the table to move things along, Malte.

I think the Greenpeace implementation can serve as the basis for a design.  I just want to expose it to the normal community participation process and get consensus before anyone asks for the code and takes off running.

So ... it's important for me to get my rough draft document describing our approach out in the open.  Feel free to bug me.  This thread makes it clear that we need to start moving.

Now ... if we get some sort of consensus that the GP work is a reasonable base and I get the relevant pieces of the GP source bundled up (so no one needs to wade through the whole thing looking for them), then I think your offering a small reward for implementation would be a great thing.

And I'd be glad to assist someone in the sense of answering questions etc with them taking home the prize fund.  It would be a help to me to see someone else pick up integrating/rewriting this stuff into the core (again, assuming that we get consensus over the approach).

One issue ... it's not efficient to have a half-dozen folks chasing after a reward (large or small) when only one version of the work's going to be accepted.  Is there some way to put together a fair process so we don't have folks duplicating effort yet give everyone a fair chance to participate in paid work of this sort?  Keeping the amounts modest helps in that not everyone will fall over themselves to do a week or so of work for $400 ...

Posted by Chris Rasch on
"'s not efficient to have a half-dozen folks chasing after a reward (large or small) when only one version of the work's going to be accepted. Is there some way to put together a fair process so we don't have folks duplicating effort yet give everyone a fair chance to participate in paid work of this sort? Keeping the amounts modest helps in that not everyone will fall over themselves to do a week or so of work for $400..."

You may wish to check out my article The Wall Street Performer Protocol: Using Software Completion Bonds To Fund Open Source Software Development. It's dated, and long, but it may spur some ideas for allowing developers to get paid, without interfering too much with the development process. It offers one possible solution to the problems of a) wasteful duplication of effort, b) properly identifying and rewarding those who contribute to the work (including non-programmers), c) allowing those who cannot/will not code to signal which features they would be willing to pay for.

Posted by Jun Yamog on
Hi Malte,

Sorry for the misinterpretation.  Anyway I still think the idea is ok it may just need to use a different approach.