Community
Participate
Working Groups
Situation We are developing a multilingual program in English. We do the German translation ourselves as we are German speakers. For the translations we use the wizard. We use one central property file for the application Problem Since Eclipse 3.0 the wizard adds the new translated properties anywhere in the file (and not at the end as in 2.1). So for us it is not possible to copy the new English externalizations in the German file and translate them. This way it is impossible to add the new German translations by hand. The consequence is that we do not use the wizard anmore, and externalize manually at the file end :-( Questions - Is this a bug, or did it happen on purpose? - Is there a possibility to configure the wizard to add the new translations at the end again? - Do you have any suggestions how we shall change the way we externalize to resolve this problem?
Moving to JDT UI
This change is by design. The new key/value pairs are inserted alphabetically using the key (which IMO makes more sense than simply adding them at the end). This will keep group of keys together.
Questions - Is this a bug, or did it happen on purpose? By design. Happened a long time ago (3.0 I think) - Is there a possibility to configure the wizard to add the new translations at the end again? No. >- Do you have any suggestions how we shall change the way we externalize >to resolve this problem? No, except to switch to the new Eclipse NLS mode (http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core-home/documents/3.1/message_bundles.html), which is currently unsorted but might be sorted in the future as well (see bug 89503).
*** Bug 69995 has been marked as a duplicate of this bug. ***
*** Bug 197999 has been marked as a duplicate of this bug. ***
Here are a couple of reasons why sorting should not happen: - as suggested by Markus, leaving unsorted makes easier maintenance tasks when resources are added, removed - for the persons actually performing the translation, it is often helpful that resources related to the same context stay grouped together. On the other hand, it is practical that all keys with the same prefix are grouped. Therefore what would be the ideal for me is the following: - inside a file, resources are grouped by their prefix - inside each group, keys are left unsorted - when the resource file is created, resource groups are sorted by the prefix (if any) - completing an existing resource file: add new resource to existing group if it exists, otherwise insert the new group where it should.