|
XPages: localisation questions and the dark side of XPages.
Julian Buss, April 2nd, 2009 20:26:26
Tags: XPages
In my current XPages projekt I want to deliver my application in english and german. So, I have the need for localisation.
In brief, localisation of a XPages app works like this:
Sounds good so far, doesn't it? Now, think again: 1. What is with literals used in script libraries? 2. What is if you change the design of a XPage after the property files were created? 3. How complicated is it for a translator to work with the property files? Did you thought about that? Well, here are the answers: 1.) What is with literals used in script libraries? You have to add adequate properties to your file manually and use getProperty() in your scripts. 3.) How complicated is it for a translator to work with the property files? I will answer 3.) before of 2.) because 2.) is more fun to talk about :-) A property file looks like this: --- #Sun Mar 29 20:41:39 CEST 2009 tabPanel4/xp\:table[1]/xp\:tr[4]/xp\:td[1]/text()=[en| HTML nach Text\: ] tabPanel2/@label=[en| Seite\: Registrierung ] tabPanel4/xp\:table[1]/xp\:tr[3]/xp\:td[1]/text()=[en| Text\: ] tabPanel3/@label=[en| Seite\: Nach Registrierung ] --- It is a simple text file, so you will work with a text editor. It is not a table or so, you will have to move around in the text very often, which wastes time. And if you give that file to a translator who is not a developer, you will have to explain a lot of things. 2.) What is if you change the design of a XPage after the property files were created? Rethink the technique again: you finish your development. You create the property files. You translate them. Then, you change something in some XPage because there is a bug to fix or an enhancement to make. Then the property file in your development language changes automatically by Designer to reflect your change. The property file changes. The property file changes. The property file changes. That means, your already translated property files in the other language have to change, too. That means, your already translated property files in the other language have to change, too. That means, your already translated property files in the other language have to change, too. So, either you let Designer create the new versions of the other language property files for you. Then all your translation work is simply lost. Or, you need a third party tool to compare old and new version of the orginal property file and copy the changed lines manually, line by line, into all of your translated property files. Boy, can that be true? As far as I talked to other devs: yes: this is the way it works today. My opinion about that Honestly? I always thought XPages are too good to be true and there have to be a dark, a bad side. And here it is. This technique is totally out of the question! It has the danger of data loss and is way too complicated to work with. Hey, I will simply have a multi-language application, I do not want to invent the Heisenberg Compensator. That means I will have to come with a solution of my own. And I will. In fact, I already did a proof-of-concept which works fine. And it will use the same logic than we use in our Notes applications for years. Yes, I will share it. No, not today :-)
Comments (0) | Permanent Link
1)
XPages: localisation questions and the dark side of XPages.
Funny. When I read something like that tabPanel4/xp\:table[1]/xp\:tr[4]/xp\:td[1]/text()=[en| HTML nach Text\: ] in one of the presentations, I already wondered how this should work when the layout changes, cause it's some kind of XPath syntax. 2)
XPages: localisation questions and the dark side of XPages.
Yeah, this does not seem to be well-thought... I wonder if IBM plans to use this in any of their own apps. And if so, how exactly they do that. But I'm not bad at the devs... XPages are so good stuff that this flaw is forgivable... even more since I came up with a much better solution :-) 3)
XPages: localisation questions and the dark side of XPages.
"you need a third party tool to compare old and new version of the orginal property file and copy the changed lines manually, line by line, into all of your translated property files. " (It's not manual if the tool does it.) This is pretty much how the localization industry works. (Look up "Translation Memory/Übersetzungsspeicher?" in wikipedia.) You might check out Notes Global Workbench, the professional tool supplied for translating Notes databases. You could probably use it for this, but I'm not sure about the specifics. But the basic approach is to start with V1's English lexicon and V1's German lexicon. You then add V2's new English lexicon. It produces a V2 German lexicon with everything that hasn't changed intact, and the English (marked up) in the places that are new or have changed. This is then typically handed off to a Translation Agency who do the actual work for translation. You get the file back. If it was a Notes datbabase, NGD would merge it back in. But for this it's just a question of dropping the right property file in the right place. I'm sure there are also plenty of other 3rd party solutions. 4)
XPages: localisation questions and the dark side of XPages.
Jo, I'm sure there are many 3rd party solutions, too. But still, for us it's much more complicated to use the properties way instead of using our own way (wich I already described in the DP forum). 5)
XPages: localisation questions and the dark side of XPages.
I just had the honor to take part at an XPages IBM mentored distant learning offering targeted at IBM's 2nd level support engineers. Let's wrap it up: Xpages currently is a pretty nice concept, but disastrous to use in serious development work. It however shows some of the Notes/Domino future as it might (MY guess ...) replace forms as we know them today, as soon as the standard Notes Client properly handles HTML - and as soon as XPages work the way forms are working today. And, it's not only internationalization issues which build the dark side of Xpages ... but we all know this, don't we? 6)
XPages: localisation questions and the dark side of XPages.
Stephan, I do not agree with you. I'm in heavy development with XPages for some weeks now, and they are a joy to use. What is disastrous from your point of view? Beside the localisation (which I solved for me in another, elegant way) I found nothing yet what hindered me from reaching my goals. And I'm building pretty tough stuff here, believe me :-) And yes, from my point of view, XPages are the future of Domino development, even on the client. |
|
|
Julian Buss/YouAtNotes Blog News and stories of a Lotus Notes developer, consultant and entrepreneur. |
|
