A wise old hermit known only as =?iso-8859-1?Q?Aslak_Helles=F8y?= <[EMAIL PROTECTED]> once said:
> Off-topic: http://rinkrank.blog-city.com/readblog.cfm?BID=16666 As if it didn't take long enough to read all my mail, newsgroups & the SF forums, do I have to read everybody's blogs as well now? ;-) Please, if it's relevant to XDoclet, discuss it on the mailing lists FFS - that's what they're here for... > Do we really need localised messages? Yes. I find it ironic that of all the developers I seem to be one of the biggest supporters of localisation. Isn't it meant to be us English that are the worst nation for learning foreign languages? [Remaining quotes from the above-mentioned blog:] >When one developer updates the original (usually English) text, all the >other localised texts must be updated too. That's precisely why we need to build the base language jar for translators with each version. It's a fixed target for them to aim at, rather than having to update it every time a message changes. Plus, without this jar the properties files are scattered all over the place, throughout all the modules' jars. Easier for the translators if they're all in one place. I notice the build script's stopped generating that one, though - anyone know why that was done? I know nobody sent us any translated versions of the previous 1.2 release, but that didn't particularly surprise me since it's only a beta version. We could at least have waited to see if there was any response to the 1.2 final release... >No one developer is likely to >know all the other languages. They don't need to. When people have problems, all it takes to find the relevant key is to mount the translation jars in your IDE and do a search on a few words. Heck, you may even find whoever translated it in the first place is more inclined to help out with the problem as well, so less of your time gets spent on the support... Failing that, just ask them to take the localisation jar out of their classpath and try again (we can even add something to feedback.html to that effect). The biggest headache in this case is that the localised copies are also in the main jars, so it's harder to exclude them. >Imagine a project that supports 10 languages/locales. It just won't be >maintained. This actually happened with the message above. Those of you >who know Portuguese will notice that the text is nonsense. I know, >because I updated the English counterpart some time ago. I thought: "Err, >I wish I knew Portugueses. Heck, some of the Portuguese-savvy developers >will come around and update it. I'm sure they read all the CVS logs every >day". Well, it didn't happen. Which was why we only included the English in the tags originally. IMO Marcus would have been better to just create a xdoclet-translate-1.2.0-beta1_pt_br.zip rather than add the second language into the source. As for hoping someone would see it in the CVS logs and update it, did you add a "@todo Update Portuguese translation" when you changed the message? That's one way we could handle it. >On open source projects people come and go. Localised messages are often >provided by users. Sure are. That's why the developers don't need to know all the languages. >Before you know it the project is stuck with hundreds >of messages in odd languages like nynorsk and fulfulde. What do you do >when the original contributors move along to other prairies? You stop at xdoclet-translate-1.2.0_pt_br.zip and don't have a xdoclet-translate-1.2.1_pt_br.zip etc. available for download. If anyone needs it, they can always volunteer to take over maintaining that locale. >I need the "official" English version, or a message id. See above. Ctrl-F works for me... >Localisation doesn't work anyway > >Just look at the message above. Wh�re d�d �ll the funny letters go? Non >UTF-8 characters never get printed correctly in my command shells. What OS? It's probably just a configuration thing. My machine didn't want to print pound or euro signs when I bought it, but it does now. > Ok, >it's not really a good argument, but the technology just isn't ready for >it yet ;-) Even if that's so, where's the harm in being one step ahead of the game? When it catches up, we'll be ready for it. This mail's already getting way too long, but two more things then I'll shut up: 1) Since we (the developers) all speak English pretty well, we're probably the wrong people to be arguing over how useful it is. After all, this is xdoclet-user - we should be asking the users what *they* want. I was going to suggest we put a poll on the SF site about it, but I don't see anything on the project pages to do so. I could have sworn there used to be - or did I just imagine it? 2) How about if I volunteer to extract the existing "foreign" messages into localisation jars (so people can more easily produce English error messages for you next time, by moving/deleting a jar), tidy up the existing message files (there's still various strings with no i18n), fix the base language zip (the paths in the 1.2b1 one are screwed) and try to drum up some volunteers to do some translations (or even complete the existing ones, since they've only been done for one of the numerous Messages files anyway)? Can I have my base language jar back in the build then? :-) Andrew. Je parle le francais solo un poco mein Herr. Und mi hermano gaijin desu. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
