> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dmitri > Colebatch > Sent: 30. januar 2003 04:04 > To: [EMAIL PROTECTED] > Subject: Re: Localisation (was RE: [xdoclet-user] Problem with Ant > Integration) > > > hey guys, > > long time, no input from me... but how's this for a suggestion. > > have a build target, that takes an input locale file > > buy.flowers.for.grandma = Buy flowers for Grandma > eat.more.potatoes = Eat more potatoes > > and uses some webservice to get translations for a specified set of
Webservice for a build? Are you serious? > languages... this would _hopefully_ produce something like: > > buy.flowers.for.grandma = Kjop blomster til bestemor > eat.more.potatoes = Spis mer poteter > > for a bunch of languages. > > This can be done each time we do a release. If at the time of > releasing we > have people prepared to fine tune/rewrite the generated files, then thats > fine. > What will a webservice buy you that you can't get from a plain file? Why can't we DTSTTCPW? > This way, we (a) dont need to change the current system much, and (b) dont > need to worry (as much) about it being out of date... > > thoughts? > > cheers > dim > > ----- Original Message ----- > From: "Aslak Hellesoy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, January 30, 2003 1:40 PM > Subject: RE: Localisation (was RE: [xdoclet-user] Problem with Ant > Integration) > > > > Heh, good post :-) > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew > > > Stevens > > > Sent: 30. januar 2003 00:57 > > > To: [EMAIL PROTECTED] > > > Subject: Localisation (was RE: [xdoclet-user] Problem with Ant > > > Integration) > > > > > > > > > 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... > > > > > > > Hey, I'm trying to make a living! Blogging is (currently) a good way to > > brand yourself and backstab others! > > > > > > 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? > > > > > > > Indeed. > > > > > [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 > > > > Spot on! If it's all in one place, there is a remote (versus minuscule) > > chance that localised/localized messages will actually be updated as a > > result of an update to the "master" messages. > > > > > 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. > > > > > > > I'm not against localised messages per se. I'd love to have hundreds of > > languages. But so far experience tells me that it's too > hard/impossibe for > > people to contribute/maintain other languages. Reasons: > > > > 1) Messages are scattered around in too many different files. > > 2) The format is too awkward for humans. Class files with fu''ny > > tag'''''''s. > > > > XDoclet's current localisation mechanism was designed for a > computer, not > > for humans. Let's come up with a format that's easier for mortals to > > contribute/maintain. In my opinion that would be one single global > > properties file a la: > > > > buy.flowers.for.grandma = Kjop blomster til bestemor > > eat.more.potatoes = Spis mer poteter > > > > One file for the entire XDoclet or possibly one for each plugin. > > > > I think we should reduce scope a little. Currently we're trying to be > > polyglote in both the generated code (various comments in various > generated > > files). That's overkill imho. It's sufficient to support multiple > languages > > on the message level (error/info messages issued from XDoclet when it's > > running). > > > > The majority of this kind of messages are generic, such as "you must > specify > > value X" etc. and can therefore be part of the core. I don't think there > is > > a big need for individual messages on the plugin level. Even less so in > the > > generated code. (After all, we're in the code generation > business, not the > > translation business ;-)). > > > > > >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. > > > > > > > Ideally, yes. -But how many people regularly read the generated > todo list? > > We have multiple dozens of unresolved bugs and rfes. I really > don't think > > anybody reads the todo lists. (The @todo support was one of my first > > contributions to XDoclet. I have never used it myself :-)). > > > > We need a more pragmatic approach. Something dead simple and in > your face > if > > we want to maintain multiple languages. > > > > > >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. > > > > > > > And that's why the format needs to be digestible by plain mortals (aka > > users). > > > > > >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. Whire dmd cll 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. > > > > > > > This was the humorous and not serious argument. But since you > ask: Win2k. > If > > I try to System.out.println("aoa") I get funny "cartoon swearing > characters" > > outputted in my command shell. If I can't get this right, do you think > John > > Doe would? ;-) > > > > > > 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 > > > > The brazilian guy (Olivier) prefers English over Portuguese. I > think most > > people using XDoclet are fine with English. This is not Microsoft > > Powerpoint. We're not writing software for our mothers (no offense). > > > > > 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? > > > > It looks as if SF removed them. I'll send a seprate voting mail where > > everyone can vote. > > > > > 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? :-) > > > > > > > I really would prefer a simpler format/mechanism such as one > single global > > properties file as described above. No funny java classes with > funny tags > > and a separate build procedure in order to produce properties files. It > > serves the same goal (plusieurs langues), but in a mucho simpler way. > > > > Doable. > > > > Aslak. > > > > Good night. > > > > > > > > Andrew. > > > > > > Je parle le francais solo un poco mein Herr. Und mi hermano gaijin > desu. > > > > > > > Ok :-) > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > ------------------------------------------------------- > > 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 > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
