Well, xml has the notion of 'lang' on attributes so that would be my fisrt choice.
For descriptions, that is easy and whether this attribute/element really holds the value or just an el that references to an external properties file (the java way) is debatable but not realy important.
For tasks it is a different story, since the task name (without the lang attribute) is really used as a value, so not many options there, unless adding additional name elementes with lang added does not pose a problem.
One other solution is to teach the Walloons to speak Dutch since with 31% they *are* the minority ;-) (but in the mean time teach Tom how to speak French)
The thing is, you do not need to change the core initially: http://planetjbpm.wordpress.com/2009/07/05/73/
I'm not sure if i18n should be done on the jBPM level. Imo, translations should be done in the 'normal' Java way (ie with resources and placeholders that are resolved when the view is rendered).
The story is different for taskforms, there is the situation not the same.
So, then your opinion is that the translations are not part of the definition?
The result of this approach is that you can change a translation without a new deploy. The drawback of this is that in this case there is not a track of this change.
So for the system you propose (normal 'Java' way) I assume that I just have to base my placeholder on the tasks name since that's the Taks 'Key' field?
I have my doubts... task also has an attribute called description. Why should that be there and a translated description not? (regardless of easier redeploying or not)
With regard to this, I Would have liked a separate name and id on the nodes where you transition to the id but can display the name. Both can be the same (and will be if not edited manually) but don't have to be. Often I run into translating spaces in names to _ since I cannot use the name as an 'id' the way it is. This is not a jBPM4 issue btw, was/is also a 'problem' in 3. (sorry for partially threadjacking)
No problem for thread jacking.
I agree on the fact that you would like a separate id and name. This would simplify some things.
Correct me if I'm wrong but for the moment and don't even find a description attribute for task.
The description is in the XSD at least. Not seen if it is in the code as well.
translations should be done in the UI layer. we won't pursue this in our console any time soon, i think.
but you can always leverage the core engine and build translations on top of it.
<task name="mytask" form="myform"...
String lang = ...get the user language...;
String formResource = task.getFormResourceName() + "-" + lang + ".form";
...render the form...
Will get you the form in the specific language.
Also your form technology would have to be capable of resolving the form parameter keys to translated texts where appropriate.
In summary: we want to make sure that the engine allows for you to build your translatable forms on top of jBPM. But we won't be shipping translation features out of the box any time soon.