Feature Suggestion: Online-Editing of language resources

[Olaf Kock, módosítva 15 év-val korábban]

Background
I've had some merge-problems as noted in this thread. I believe the manipulation of the language files currently is too hard. Some reasons for this are

• the sheer size of the language resource files
• multiple people contributing (which is actually a good problem to have!)
• it naturally takes a while until contributed solutions are committed to svn
• when contributions are committed, usually more additions have been made that need new translations and it's not obvious which of the many entries need attention

Suggestion
I'd like to suggest some online editing capability that abstracts away the language files and provides a possibility for users - just like in a wiki - to provide translations. This can provide the opportunity for a lot more usecases than just simultaneous editing of entries:

• It lowers the barrier to edit a single entry
• It provides a definitive place to go to for translations
• It should make it easy to add new entries so that it's only a last resort to use horrible machine-translation
• It enables feedback to the authors of the original english texts that are sometimes ambiguous - e.g. context is missing or it's unclear if verb or noun is to be translated
• It might provide the context for a single entry as documentation without the comment appearing in the actual file (might remain in database)

Discussion
Before creating such a beast: Does somebody know of existing components (ideally in portlets, but anything might help) that do provide such features (or more or similar or less)? Would liferay (the company) be willing to evaluate to change their development environment to a model where language files are generated from database once such a component exists? Is this idea completely daft? Would somebody like to collaborate on this?

I'd like to know what you think of this.
Thanks,
Olaf

[Jorge Ferrer, módosítva 15 év-val korábban]

Hi Olaf,

I think it's a great idea. Actually Brian Chan has suggested a similar idea several times but we just never had time to define it properly and implement it.

If you go ahead I'll try to help as much as possible and find a way to make the portlet that implements it available in liferay.com

I think that portlet should be able to 'export' the translation as a Language file and then when a release is made the Liferay release manager would go and grab the latest version for each language and include it in the release. We'll have to find a way so that edits from 'trusted' users are applied immediately while those by occasional contributors go through an approval mechanism.

[Olaf Kock, módosítva 15 év-val korábban]

Good, thanks for the feedback - I'll start with writing up some scenarios to get my thoughts channelled. I'll tell you when/where I publish them. Finally, this is a good reason to get deeper into portlets. I suppose that the UI will not be that complicated, so that almost any UI-technology might do.

[Alvaro Amor Morales, módosítva 14 év-val korábban]

Hi,

I have been looking for that functionality, DB backed messages, and I have found some code in SourceForge that can be integrated with Liferay. It is a custom PropertyMessageResources that reads the messages from database and you can configure a reloading timeout, even if you want to reload the properties on demand, you can clear the cache and then the messages will be reloaded. The integration seems easy because you only need to overwrite the message-resources tag in the struts-config.xml file using the extension or a hook, and load the messages in the databases.

You can find this module here:
http://sourceforge.net/project/shownotes.php?release_id=320056&group_id=49385

And you can create an interface for that table using the ServiceBuilder and creating a portlet to maintain this table or try something like OpenXava (http://www.openxava.org)

Regards.

[Jason E Shao, módosítva 14 év-val korábban]

Any thoughts on switching from property file-based l10n to perhaps db backed? I know the default Java API's make that more difficult than necessary (though in Java 6 a db-backed ResourceBundle is possible -- esp. with some AOP magic to autogen the class file per Locale). Alternatively some frameworks like Spring have alternative i18n aware tags (the <spring:message> taglib for instance would easily support pulling from a db-backed MessageSource)

My main motivation here is many of my end-user administrators have expressed a desire to easily do their own translation (or terminology substitution in many cases) and editing the property files is pretty cumbersome in a ASP environment. Whereas something db backed would let us build (or leverage) a front-end UI to make this end-user enableable.

JIRA has a neat web-frontend for translation, as do many other projects.