[MAGNOLIA-281] support i18n in the GUI Created: 04/Feb/05 Updated: 26/Feb/08 Resolved: 26/Feb/08 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface, core, taglibs |
| Affects Version/s: | 2.01 |
| Fix Version/s: | 2.1 Final |
| Type: | New Feature | Priority: | Major |
| Reporter: | Boris Kraft | Assignee: | Boris Kraft |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Date of First Response: |
| Description |
|
I have the following requirements for any mechanism that deals with internationalization in Magnolia: 1) strings must be extracted automatically from java and jsp at least, hopefully also from javascript and anything else that will come along. These requirements can be solved using GNU gettext. Also see the discussion on the dev list regarding i18n and Gnu gettext. |
| Comments |
| Comment by Michael Aemisegger [ 04/Feb/05 ] |
|
| Comment by Bert Schulzki [ 04/Feb/05 ] |
|
Its a good idea to start from the requirements pov. From my experience, i would like to add some more requirements: 8) configurable behaviour on missing translations / keys 9) Cleanup of unreferences Stings 10) Unified parameter mechanism for texts 11) Context information and documentation for the translation files |
| Comment by Boris Kraft [ 04/Feb/05 ] |
|
1) No. IIRC gettext will add any key for which it finds no translation automatically to the translations file. Javascript: I said "hopefully" - I have no idea if it is necessary, or what ways we can find to avoid it. |
| Comment by Boris Kraft [ 04/Feb/05 ] |
|
8) could be solved through the fact that the admin GUI for translations simply shows you if a translation file is complete resp. its completeness percentage. You will see in a blink if any translations are missing for any language. 9-11 agreed. |
| Comment by Michael Aemisegger [ 04/Feb/05 ] |
|
1) So does eclipse. Maybe I formulated it unclearly. Eclipse searches for strings in any marked package (e.g. all), finds not yet translated strings, lets you select or deselect any string, updates the class with the corresponding, configurable code, updates properties files, generates necessary helper classes and lets you review all this stuff before applying. I would call this pretty automatic. You have to start the wizard manually, though. Maybe an ant/maven task can do it. Does IIRC gettext also refactor java classes? With this question I don't want advocate java resource bundles but to emphasize IDE support. |
| Comment by Boris Kraft [ 04/Feb/05 ] |
|
The eclipse plugin sounds pretty impressive! However, I don't want to be dependent on an IDE to perform that task. If you remember, gettext also uses the java resource bundles as a data source if you want. So one does not exclude the other, it seems to me. Lets move a step forward. Can you provide an architecture and process description of how you propose to solve the requirements? As I said before, I don't care about the technology, I care about the results. If what you propose addresses the issues, lets move. |
| Comment by Michael Aemisegger [ 04/Feb/05 ] |
|
I'll give it some thought and will put it into some kind of document. So, can you somehow provide me with your gettext engine or give some examples of usage? It would be easier to compare the two (maybe complementary) approaches. |
| Comment by Fabrizio Giustina [ 05/Feb/05 ] |
|
Downloaded gettext, read documentation and tried tools. First of all, here are a couple of links for localization editors (better then gettext utilities, AFAIK). This are the editors for translators, not developers. http://ostermiller.org/attesoro/screenshot.html And now, let's try to explain how we could fullfill requirements. 1) strings must be extracted automatically from java and jsp at least, hopefully also from javascript and anything else that will come along. This can be done with many java IDE. Eclipse is probably the best tool, Jbuilder has a great support too and I think IDEA has something similar. Note that this is a developer step, the requirement of a java IDE is only for the initial extraction of resource (let's say for extracting the first english translation), it's not needed at all by translators. 2) anybody must be able to do translations even if he has never written a line of code before A lot easier using java resource bundles than using gettext. You simply need to edit a text file, and there are lots of good editor for that (see previous links) 3) it must be easy to detect if new strings have been introduced into the program Eclipse does this automatically, and I think other java IDEs can. 4) translations must be easy to distribute They are just properties file. 5) the system must support the idea of having "private" translations as well as the standards translations. With that I mean that if I write a custom module, I should not be forced to put its translation into a global translation file. Or to put it otherwise: some kind of hierarchical or cascading mechanism must be possible. You can organize translations in different bundles, so you can have a core file, a file for each module, and so on. 6) it must be easy to add your own translations (go to www.magnolia.info, check if translation to "schwäbisch" exists, if not, click "add translation", type "schwäbisch", download po files, start your editor, translate to your hearts content, upload the file, thats it.) Download properties file (and an editor to simplify the work). Upload the new properties file. 7) Installation of the new language must be supported by Magnolia directly Mh... well, for this we should need on a new - custom - feature in admin interface, which let you upload the new properties file and save it in the classpath? Is this what you are referring to? 8) configurable behaviour on missing translations / keys By default if a message is not found, the key is found. It could be pretty easy to setup a framework which will use the english resource if the translated one is not found, but IHMO this should not be a problem in production environment since translation must be complete before a release! 9) Cleanup of unreferences Stings Probably you can do this with eclipse 10) Unified parameter mechanism for texts Stantard java i18n + messageFormat 11) Context information and documentation for the translation files Comments can be added in properties file for translator. On the other side, for developers, eclipse is able to directly show the value of a resource bundle key while looking a java file (new in eclipse 3.1, a killer feature And I add: Can we close this thread and starting Magnolia i18n using this proposed solution? |
| Comment by Boris Kraft [ 05/Feb/05 ] |
|
One more thing: I don't want to be forced to use arbitrary keys for my strings. Keys should be the English source text. I cannot imagine how anybody can ever come up with a scheme for arbitrary keys that work in a mid-sized project. Is it possible to use the original text string as key? |
| Comment by Boris Kraft [ 07/Feb/05 ] |
|
re 7) I have opened a separate issue: http://jira.magnolia.info/browse/MAGNOLIA-286 |
| Comment by Bert Schulzki [ 07/Feb/05 ] |
|
Hi Boris, > One more thing: I don't want to be forced to use arbitrary keys for my strings. Keys should be the I would not agree with that statement. I did some larger projects with artificial keys and i see no problem with it. By using natural language as a key you are forced to retranslate the whole package, as the key is no longer valid (and therefore its translations). Using keys that have a business meaning is generally dangerous in software development. But i see your point for usability reasons for the developers. For their convinience different solutions could be used:
The approach depends of the technical possibilities of the framework of course. The second approach is very similiar to yours, but with the difference that you would still nee a translation even for english (which is in fact not a problem, as developers rarely do frontend texting). From developers pov the difference is instead of using i18n.getText("The page was successfully deleted.", locale) the would call i18n.getText("deletePageSuccessMessage", locale). |
| Comment by Boris Kraft [ 07/Feb/05 ] |
|
Hi Bert, I see your point about business meaning in keys. If one can stick to the action instead of the message, that might work. I was just wondering how subtle differences in what you want to say in similar situations can be dealt with. How do you know that a key already exists for what you want to say? Or vice versa, how can you avoid that it does? Say your "save" goes wrong, simply to state "SaveFailed" will probably not suffice to communicate what you want to say in any particular instance of save failure. Should we use a naming convention that includes the module, page/node, action and result? E.g. LinkChecker_ResultPage_ShowInvalidLinks_NoViolationsFound I think it would make it easier for devs if strict guidelines exist - we need to think less about it. Any experience with such a scheme? |
| Comment by Bert Schulzki [ 07/Feb/05 ] |
|
> How do you know that a key already exists for what you want to say? Or vice versa, how can you avoid Well, you cant. But thats no difference to natural approach (think about "Okay", or "Done"). But the text provider class should already have a smaller scope to avoid naming conflicts. E.g: I18nResource linkCheckerRes = I18nResourceFactory.getI18nResource("linkchecker", locale); That has also the advantage of shorter calls to the resource as the locale is not needed for every call: String msg = linkCheckerResource.getText("ResultPage.ShowInvalidLinks.NoViolationsFound"); > Say your "save" goes wrong, simply to state "SaveFailed" will probably not suffice to Right. Therefore different keys could be needed, one for each failure. Thats indeed very close to the natural key apporoach. Maybe something could also be done with arguments, e.g. an error number and the original server response: String msg = linkCheckerResource.getText("ResultPage.ShowInvalidLinks.Violation", new String[] {"404", "File not found"}); > Should we use a naming convention that includes the module, page/node, action and result? E.g. Absolutely agreed. The module name itself (and possible submodules) could be already contained in the resource object, so the path would be even shorter (see above). |
| Comment by Michael Aemisegger [ 07/Feb/05 ] |
|
I have made good experience with schemes like global.ok bar.edit.move news.date
|
| Comment by Philipp Bracher [ 14/Mar/05 ] |
|
I start working on that topic and I agree more or less to the comment of fabrizio (5.2.05). If no one insists I will do it this way:
This solution solves the requirements as follow: Not solved: Pros
Contras
|
| Comment by Michael Aemisegger [ 14/Mar/05 ] |
|
How will i18n be solved for javascript files? Are there any best practices? To be honest I have no experience at all to do a generic javascript solution. Generating javascript files with JSP might be one option. |
| Comment by Philipp Bracher [ 14/Mar/05 ] |
|
I propose the following:
This means: we keep i18n out of the javascriptcontext. JSP (the tags) shall handle it. my arguments are:
|
| Comment by Philipp Jurewicz [ 16/Mar/05 ] |
|
Hi Magnolia team I'm not an active magnolia user but I follow your mailing list, just want to comment a bit. I used jstl:fmt on an other project and it works fine. You can set the fallback locales in different levels (web.xml, your framework, jsp) so it is safe to let the logged in user to change to his/her prefered language. You can program interceptors so in a MVC scenario your controller also knows the locale (I read somewhere you want to switch to MVC someday)(My jstl:fmt experience is on spring-framework) I wouldn't be to strict with only releasing a locale when everything is 100% translated. Magnolia is growing pretty nice right now and when the core modules are 100% translated it's great, but when an admin wants to snap in a new module (like news) it would be ok if it's still in english. If the deployer has an interest in having the module in his clients language it is a nice starting point for contributing. Of course the maintaing translater should superreview it, but language superreview is easier than code superreview. Eclipse has some plug-ins for working with locale (panels side by side /trees etc) so you "could" call it the gui for the translater. Though downloading a 80MB Eclipse to work with a tine property file is a bit odd. For the translation of JavaScript my thought would be: If you want to avoid the problem of JS-dependencies while loading into a browser you can paste the content of the JS-locale file into a <script> tag in the JSP right before it calls the JS logic file. This is possible because JS-script files have a very flat structure. They essentially beginning code in the first line. Drawback of this is you bloating your HTML code with repeatitive code. on the other hand thirty or forth JS-constants are not sooo much code for clients which are sitting on LAN or broadband to maintain their magnolia installation. If you want to do it "deluxe" or on the other hand unnecessary complicated you could maintain your JS-locale-key in Java-property files (so all your translators have only one filetype to cope with) and parse them to JS constants and paste them right infront of the <script src=""> code. One should always be carefull with global JS, so one should consider some namespace, or encapsulate it in a simple JS object which can be passed by a constructor argument to the JS logic. Last I'm pretty sure you are already using this but just in case: Keep up the your good project! like it, just not using it yet. |
| Comment by Philipp Bracher [ 26/Apr/05 ] |
|
i added some new tasks |