Antoine Toulme wrote:
On Tue, Jan 20, 2009 at 2:32 AM, Sean Flanigan <sflaniga@xxxxxxxxxx
<mailto:sflaniga@xxxxxxxxxx>> wrote:
Well, no, I haven't. I was just trying to ask a general development
question, and Antoine turned it into a cross-project bug report
snowball! ;-)
My followups to wtp-dev and birt-dev were really for the sake of
completeness. (I was going to follow up to cross-project, reluctantly,
but fortunately I was able to identify the offending projects in this
particular case.)
No worries Sean. I take all the blame happily. I think people are not
aware enough that globalization is important. If we wait the last minute
to run a review, we won't be able to make that happen.
You've got that right. Even with a code patch, it can take 9 to 12
months: https://bugs.eclipse.org/bugs/show_bug.cgi?id=215116 . Not
meaning to criticise Mylyn, I can see they're doing it very thoroughly.
But it's a shame that externalisation patches are just complicated
enough to be a concern from a development point of view and a legal one.
They tend to produce a large enough diff to look substantial (even when
they're not) and obscure enough to make it unclear if anything might
have broken.
It was also designed to avoid having you open a bug against each of
those projects, because I was sure it would discourage you the next time
around. I hoped they would reply with a bug number.
Thanks Antoine, I do appreciate that. But since it is what I get paid
for, I decided to grit my teeth and have a go.
(Well, I think I'm supposed to be a programmer, not a tester per se, but
I'm not really in a position to start internationalising all the Eclipse
projects. And even if I tried, there's a good chance they'd end up like
the Mylyn patch above. It's happened before.)
There is still no way as of today to find non externalized strings
programmatically. I'm racking my brains against my keyboard about this
stuff, but I don't see a way to make that happen. So an email blast is
the best way to warn devs about this for now.
I like my idea of recording stack traces when creating GUI components.
(I would, wouldn't I? ;-) Ideally, if you (say) Alt-clicked on a GUI
component, it would parse the stack trace, launch a web browser on CVS
View for the relevant source code, or (for externalised strings)
directly to the Babel page for that translation.
Unfortunately, those stack traces would probably consume far too much
memory and CPU, not to mention the difficulties of intelligently parsing
the stack trace. And deep hacking on SWT code.
But how about tackling it from the source code end? The Eclipse
compiler certainly knows how to detect non-externalised strings. Is
there any way we could make these into hard-to-ignore warnings (and
eventually errors) when building Eclipse.org projects? It really needs
to be done as part of the normal, individual builds, or the right people
would never see the messages.
Obviously, this sort of static analysis won't catch everything, and it
doesn't guarantee that programmers will externalise the right strings,
but it would have be an improvement.
Are there any cross-project coding standards which might be relevant?
I have a tangential idea for simpler externalisation testing (as in
pseudo langpacks), but I'll put that in another post.
Regards
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
