Translations

Last modified 30 May 2023 12:12 +02:00

Translators

The easiest way to participate in midPoint localization is to use Transifex.

The whole localization process is described on Transifex page of this wiki.

A few tips for externalization of strings:

  • Be consistent! Describe same things with the same names.

    • For approvals, follow this terminology

    • By default, follow general terminology

    • Use same phrases in same situation

      • Good example "Couldn’t get X", "Couldn’t check Y", "Couldn’t validate Z"

      • Bad example "Cannot get X", "Failed to check Y", "Couldn’t validate Z"

  • Restrain relevant references, like "above", "below", "on the left/right"

    • Due to responsive design, this can change

    • …​not talking about design changes, which could then lead to pain in the butt

  • Avoid referencing to actions in midPoint as "we", preffering neutral form

    • for example: "We exclude the user himself" can be better describe as "User himself is excluded"

  • Reference to user as "you" only, when you need user to take immediate action

    • for example: "Do you really want to delete {0} assignment(s)?"

    • for other examples, use neutral form: " Usually you need not change the default value" → " Usually there is no need to change the default value"

  • Avoid refering to system itself as "midPoint"

    • customer can give it other name and will be confused

    • remember Waveset/Lighthouse

    • use "System" or "it": "midPoint will pretend that this attribute does not exist" → "System will pretend that this attribute does not exist" or "It will be pretended that this attribute does not exist"

Localization service

Following table shows list of property files that localization service uses to resolve translation key. First translation found is used for translation (first file that contains key for translation).

<midpoint.home>/localization/Midpoint_<CURRENT_LOCALE>.properties
<midpoint.home>/localization/Midpoint.properties
<midpoint.home>/localization/schema_<CURRENT_LOCALE>.properties
<midpoint.home>/localization/schema.properties
<WAR>/Midpoint_<CURRENT_LOCALE>.properties
<WAR>/Midpoint.properties
<WAR>/schema_<CURRENT_LOCALE>.properties
<WAR>/schema.properties
<WAR>/com/evolveum/midpoint/security_<CURRENT_LOCALE>.properties
<WAR>/com/evolveum/midpoint/security.properties
<WAR>org/springframework/security/messages_<CURRENT_LOCALE>.properties
<WAR>org/springframework/security/messages.properties

Developers

The obvious localization routine applies:

  • Do not use strings to messages or anything that can be seen by the user. Use localization keys. Use Java and Wicket localization mechanisms (tip: Google is your friend).

  • When localizing in wicket simply use getString() method which is available in each component. Just take care not to call it directly from the constructor. Use org.apache.wicket.model.ResourceModel instead.

Now there are two localization files that contain the keys:

  • infra/schema/src/main/resources/localization/schema.properties contains all the keys and messages from the schema. Such as full name, given name, etc. If the key describes the data model (schema) then it should go there. E.g. readable names of data types and elements such as UserType.locality, FocusType.assignment, …​

  • gui/admin-gui/src/main/resources/localization/Midpoint.properties has all the messages that are specific to GUI. Strings used by the GUI widgets go here, e.g. WhateverEditorPanel.successMessage, PageFooBar.okButton, …​

When creating new GUI widgets please try to avoid creating new keys when not needed. You should try to reuse the keys from schema.properties as much as possible.

Was this page helpful?
YES NO
Thanks for your feedback