Hi
definitely a good series, a couple of points come to mind:
1) TapiJI/Babel Tools already adress some of the issues point out
in part 1 of the series, specifically:
* You need to know the keys that are available in the resource
bundle -> auto-complete and preview support
* If a key changes you need to search for the String in your code
-> refactoring support
2) solution discussed in the posts 2-4: by using fields (instead
of e.g. interface methods) you cannot pass parameters and
therefore do message formating in the background. using
@PostConstruct is only a solution for static message formating at
instantiation time, if i for example want a parameter to change
every time the string is displayed (e.g. displaying the result
count of some query) then i have to do the formatting by hand
3) I fully agree with the point made in post 4 that the
platform/application model should provide support for runtime
label changes
All in all I think the core feedback of this series (and i've
heard similar points from other sides as well) is that i18n in
Eclipse (even e4) is still more complicated and less user
(==programmer) friendly than it should be.
cheers
Stefan
On 12.08.2013 15:57, Denis Roy wrote:
http://blog.vogella.com/2013/05/03/eclipse-internationalization-part-14-current-situation-by-dirk-fauth/
Thoughts?
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev