Re: [babel-dev] Identifying (and externalising) untranslated strings

[Tod Creasey <Tod_Creasey@xxxxxxxxxx>]

The Eclipse Platform teams sets thier
projects preferences to error for non externalized Strings. This is generally
good practise for any team contributing to Eclipse.

Tod

"Antoine Toulme" <antoine@xxxxxxxxxxxxxxx>
Sent by: babel-dev-bounces@xxxxxxxxxxx

01/20/2009 12:35 AM

Please respond to
antoine@xxxxxxxxxxxxxxx; Please respond to
Babel committers mailing list <babel-dev@xxxxxxxxxxx>

To	"Sean Flanigan" <sflaniga@xxxxxxxxxx>
cc	Babel committers mailing list <babel-dev@xxxxxxxxxxx>
Subject	Re: [babel-dev] Identifying (and externalising) untranslated strings

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.
That's too heavy, and there is non GUI code you would
like to catch.


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?
Yes. Non-translatable strings are supposed to be marked
with //$NON-NLS-1$, //$NON-NLS-2$, //$NON-NLS-x$ with x being the number
of the string on the line.

And you know what... open your preferences, and go to Java>Compiler>Error/warnings.
Look at the option "Non-externalized strings".
It exactly does what we want it to do. But since its priority is set by
default to Ignore, well...

So I will do a big shout out for this.


I have a tangential idea for simpler externalisation testing (as in
pseudo langpacks), but I'll put that in another post.

Regards

--
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev