Hi Everton,
To prevent unwanted changes we only log this kind of situations like it is shown in the attachment. The log file is located at the path, whcih was defined through the –logFile parameter. First column shows the path to a file, so you can change the values manually.
If you have lots of changes, just filter all messages_pt.properties, delete them and restart the tool.
Hi Mario,
did your generated platform_cuba.xls had these lines in it? (see attachment)
For some reason, generated localization files lack several @include statements.
You can fix this manually:
edit file i18n-test/modules/gui/src/com/haulmont/cuba/gui/messages_de.properties
add this line at the beginning of the file, right after the copyright comment:
@include=com.haulmont.cuba.core
edit file i18n-test/modules/gui/src/com/haulmont/cuba/web/messages_de.properties
add this line at the beginning of the file, right after the copyright comment:
@include=com.haulmont.cuba.gui
edit file i18n-test/modules/gui/src/com/haulmont/cuba/desktop/messages_de.properties
add this line at the beginning of the file, right after the copyright comment:
@include=com.haulmont.cuba.gui
then restart your project. This should fix the issues you described.
Hi Igor,
thanks for the hint, there were no translation for these three @include entries. I just copied the stuff from the default column. Now everything works as expected.
I’ll post the final results of the german translation in the next week.
Bye,
Mario
Hi guys,
i finished the translation to german locale (for austria and swiss as well for the most part). It works for 5.6 as well as 6.0.
Do you attach it to the project, so i’ll be able to use it for myself in further projects?
Bye,
Mario
Hi Mario,
Thank you very much for sharing your work!
We are now considering the best way of providing translations. On one hand, including them directly to CUBA artifacts would be most convenient for developers. On the other, we are unable to support all translations by obvious reason - each time when we change messages in the platform we have to translate them again. So most probably, we will set up a GitHub repository and publish there the localizer tool and the set of translations separated by platform versions. The translations will be in the source form (XLS), and as JAR files to be used in projects without modifications.
What do you think of such variant?
By the way, are you sure your translation is suitable for 6.0? We have changed the location of messages for all common parts of the platform used inside application screens - visual components, including Filter. Now they are all in the main message pack, and hence easily overridable. Anyway, we can move the messages by ourselves, and just ask you to check the result.
Unfortunately, we are now very busy with Java One, so we will be able to deal with translations only in 2-3 weeks.
Thanks again!
Hi Konstantin,
sure, putting it directly into the platform would not work out that well as time goes on. Doing the changes on a Github repository seems reasonable from a “translation maintenance” point of view. But as a developer i would wish a little more convenience for importing different languages. Would a button in studio for downloading the translations and importing it to the project be possible (either download the excel files and automatically execute the binary, or downloading directly the .properties files for the correct version of the platform and the translations)?
I think it depends a little on your preferences how tightly coupled the platform should be with the “community addons” in its public image.
From a maintenance perspective it would be cool, if changes on the keys could be communicated via the Github repository as well, so there is no hurdle to translate the deltas. I’m not even sure, how this could work, but it would increase the chance that the translation will keep up with the development. A possible thing would be to use Github Issues for this.
Do you have any glue, how other open source projects handle this issue? It seems to be a solved problem, right?
Regarding to 6.0 - well when i read what you wrote, i should have said no, right? :=) What i did was to create a test project in 6, import the translation and starting it. On the surface, everything looks good. I’ll check it in the next days in a little more detail. I’ll let you know about it.
Bye,
Mario
Hi Mario,
We will definitely consider your idea about loading translation from Github by Studio. I think such kind of coupling with community add-ons is not a problem and can be implemented. We just need to make it clear to the developer that these translations are provided by third parties and can be out of date.
Notifying about changed messages in a new platform version can be done through issues as you suggested - this is not a problem as well, especially taking into account that messages in the platform functionality are changed very infrequently.
But the first step is, of course, to improve the localizer and publish the translations as is. We’ll start working on it after November, 8.
Hello Konstantin,
i tried my translations with 6.0.2 once again and it turns out, you are partially right 
A lot of stuff is translated (like the login screen, add / edit / remove buttons, reporting, bpm, cc-payments etc.), but different parts of it are not (Filter row with popups and additional options like saving filters in the filter settings menu, “Add to Set” button) but its just a few.
If you could move the message packs, it would be great, since you probably know the changes a little better. That would be great! When you post the converted xls files, i’ll just double-check it.
Bye
Hi Mario,
Sure, we will do this.
Hi Mario,
I’ve prepared for you fixed version of .xls files (actually platform_cuba_de.xls and platform_charts_de.xls).
I removed some unnecessary properties and renamed some existing. Please pay attention on three properties below, because I’ve added to them full values:
filter.customConditionFrame.paramWhereClauseHelp
filter.customConditionFrame.joinClauseHelp
filter.customConditionFrame.whereClauseHelp
I’ve also added to platform_charts_de.xls some new properties.
Hello Gleb,
it looked all fine. I added the mentioned translations for the filter keys (v. 1.0.1).
Bye,
Mario
Hi guys,
We have created the translations repository on GitHub:
https://github.com/Haulmont/platform-translations
Now it contains the reference English localization, German translation for 5.6 and 6.0 provided by Mario, and our incomplete French translation for 6.0.
Please feel free to use and modify the translations as described in the repository README.
We welcome your comments and suggestions! If you want to contribute to the repository, send us pull requests or create support topics with your fixes for discussion.
Hi Konstantin,
I’ve created a app-component for using german translation easily:
I also updated the german translation to platform version 6.3.5 in https://github.com/Haulmont/platform-translations project…
Best regards Matthias
Hi Matthias,
We’ve merged your pull request, thank you for sharing your work!
And I think that distributing translations as app components is a brilliant idea! We are going to create an infrastructure for publishing components in the near future, so it will be much easier to share and use translations this way.
Thanks again!