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
