Hi Christian, You have a lot of questions in this message :)
I would say that internationalization (aka i18n) is important quality mark for a source code. However, localization (that brings the real value for a user) is a separate effort, whatever with the help of Babel or without it.
As for i18n for specific attributes like vendor, license, copyrights and so on. I think the i18n should be done to provide a hook for local legal names and formulations. For EPL-2.0 license in particular things are a bit easier since we can specify "license-feature" attribute to reuse standard content with two steps:
1) add to target https://github.com/eclipse-passage/passage/blob/master/releng/org.eclipse.passage.target/org.eclipse.passage.target.target#L18 2) declare attribute https://github.com/eclipse-passage/passage/blob/master/features/org.eclipse.passage.ldc.feature/feature.xml#L20
Regards, AF 25.11.2020 10:29, Christian Pontesegger пишет:
I have in mind that one requirement of project graduation is I18N support. Tried to find that in the handbook, but failed. So first question: is there a list of requirements on the code and its functionalities regarding graduation? 2nd: I see that I18N is used for feature.xml and plugin.xml for fields like: * vendor * license * copyright Do we really need this? Does Babel really translate the license terms or copyright messages? The vendor will quite likely also stay the same. thanks for clarification Christian _______________________________________________ incubation mailing list incubation@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/incubation
_______________________________________________ incubation mailing list incubation@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/incubation
