[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [jwt-dev] Important : NLS messages
|
Hi Marc,
Florian discovered a few weeks ago that there is a flag on the genmodel
to makes EMF automatically generate NON-NLS tags. So that you don't have
to worry: there is no need to modify templates, but only to switch a
flag on the genmodel ;)
Mickael
Marc Dutoo a écrit :
Hi Mickaël, Florian
I'm not fond of modifying EMF templates...
Regards,
Marc
Mickael Istria a écrit :
Hi Florian,
Sure, this would be great!
I let you make this modification since I don't have experience with
EMF-templating.
Regards,
Mickael
Florian Lautenbacher a écrit :
Hi Mickael,
maybe we can simply adapt the EMF-templates here, so that each
generated
class automatically contains the annotation @SuppressWarnings("nls")? I
guess this would be the easiest solution.
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx
[mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Mickael Istria
Gesendet: 05 February 2009 11:02
An: Java Workflow Toolbox
Betreff: Re: [jwt-dev] Important : NLS messages
Hi all,
Just a special case for EMF generated classes that contains
not-externalized
strings:
If you see that the class is generated (ie comment on the class
contains
@generated), then simply add the annotation @SuppressWarnings("nls")
on that
class.
Indeed, we cannot spend so much time on generated class to manually
externalize them or to add NON-NLS, all the more that EMF strings
have a
logical meaning.
I'll add this special case in the wiki entry about externalization.
Regards,
Mickael
Mickael Istria a écrit :
Dear contributors,
Using NLS internationalized and externalized strings is a really
important requirement for Galileo. So, I urge all of you to mark
non externalized strings as warnings (or errors) while you are
developing.
That way, you'll be easily able to see which strings are
externalized and which are not.
I attached a screenshot that shows where to activate these
warnings. Here are some other resources on this topic if you're
interested:
*
http://www.lunar-ocean.com/eclipse-committers-turn-your-nls-warnings-o
n/
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=261766
*
http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.d
oc.isv/reference/misc/message_bundles.html
* ...
Concretely, here are some good practices for NLS:
* If your string is related to UI, then it *must* be externalized
and referenced from a NLS Message Bundle
* If your string is a "logic" string (for examples if it the name
of a plugin extension point attribute, or "true"/"false" strings)
and if it is used several times, then create a constant for that
string and use it.
* It your string is _never_ intended to be displayed (for example
log messages or bundle names...) then, add a //NON-NLS-n comment.
I've already externalized or NON-NLS-ed most of strings in we and
transformations plugins. However, some of them probably still remain.
So please take care of it in your next developments, because it is
quite time-consuming to do it in after development on existing code.
Regards,
Mickael (stressed by bug 261766 ;)
----------------------------------------------------------------------
--
----------------------------------------------------------------------
--
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
