Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: Trunk
    • Component/s: party
    • Labels:
      None

      Description

      I'd like to contribute some more german translations, and I also changed some of the existing terms to sound more german because the provided translations seem to be literal translations

      1. MarketingUiLabels.patch
        0.6 kB
        Martin Kaiser
      2. PartyUiLabels.patch
        69 kB
        Martin Kaiser
      3. SecurityUiLabels.patch
        6 kB
        Martin Kaiser

        Activity

        Martin Kaiser created issue -
        Hide
        Martin Kaiser added a comment -

        Label patch file

        Show
        Martin Kaiser added a comment - Label patch file
        Martin Kaiser made changes -
        Field Original Value New Value
        Attachment PartyUiLabels.patch [ 12530010 ]
        Martin Kaiser made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Hide
        Martin Kaiser added a comment -

        Security Labels patch file

        Show
        Martin Kaiser added a comment - Security Labels patch file
        Martin Kaiser made changes -
        Attachment SecurityUiLabels.patch [ 12530011 ]
        Martin Kaiser made changes -
        Attachment MarketingUiLabels.patch [ 12530012 ]
        Show
        Adrian Crum added a comment - https://cwiki.apache.org/OFBIZ/dictionary-for-translations-to-german.html
        Christian Geisert made changes -
        Assignee Christian Geisert [ chrisg ]
        Hide
        Martin Kaiser added a comment -

        I contributed the files with the translations without having knowledge of the 'dictionary for translations'. So maybe some of the translations might not be the official translations of this dictionary. But I think also that some of the translation do not really match the correct term in each and every case. So, it's up to you if you want to integrate the translations. (e.g. 'expire', I don't think that 'ablaufen' is the correct term for a button label, and could have the meaning 'erloschen' in case of an postal address, or 'beenden' in case of a contract. So it depends on the situation in which it is used.)

        If not I could review the patch files and also make some suggestions to the dictionary.

        Please let me know.

        Show
        Martin Kaiser added a comment - I contributed the files with the translations without having knowledge of the 'dictionary for translations'. So maybe some of the translations might not be the official translations of this dictionary. But I think also that some of the translation do not really match the correct term in each and every case. So, it's up to you if you want to integrate the translations. (e.g. 'expire', I don't think that 'ablaufen' is the correct term for a button label, and could have the meaning 'erloschen' in case of an postal address, or 'beenden' in case of a contract. So it depends on the situation in which it is used.) If not I could review the patch files and also make some suggestions to the dictionary. Please let me know.
        Hide
        Adrian Crum added a comment -

        That type of difference is worth discussing. Some UI label keys might be chosen based on their English translation, but that choice might be inappropriate for other languages. Your example is a good one:

        1. Expire postal address. The postal address did not cease to exist, but perhaps a relationship to it ceased to exist. A better English description would be "No longer applies" - so the UI label key could be improved to indicate that.
        2. Expire contract. The contract did not cease to exist, but its period of enforcement ended or concluded. A better English description would be "Period Ended" or "Period Concluded" - so the UI label key could be improved to indicate that.

        In both cases, the translation to English would remain "Expire" (since the meaning of expire depends on the context), but the UI label keys can provide more detailed information for other translations.

        So, maybe we need some additional UI label keys to make some of those distinctions.

        Show
        Adrian Crum added a comment - That type of difference is worth discussing. Some UI label keys might be chosen based on their English translation, but that choice might be inappropriate for other languages. Your example is a good one: 1. Expire postal address. The postal address did not cease to exist, but perhaps a relationship to it ceased to exist. A better English description would be "No longer applies" - so the UI label key could be improved to indicate that. 2. Expire contract. The contract did not cease to exist, but its period of enforcement ended or concluded. A better English description would be "Period Ended" or "Period Concluded" - so the UI label key could be improved to indicate that. In both cases, the translation to English would remain "Expire" (since the meaning of expire depends on the context), but the UI label keys can provide more detailed information for other translations. So, maybe we need some additional UI label keys to make some of those distinctions.
        Hide
        Adrian Crum added a comment - - edited

        To make what I'm proposing clearer, I can use a simple example.

        An OFBiz developer wants to create a UI label for the word "second" and creates a UI label with the key "CommonSecond". In English, the word "second" has two meanings: ordinal and temporal (after first, and 1/60th of a minute). Since only one UI label exists, it is used for both meanings. But in other languages, they might be different words - so they require different UI label keys. A better approach would be to have two UI label keys: "CommonSecondOrdinal" and "CommonSecondTemporal". Both keys would be translated to English as "second" - but other languages would be free to use different words.

        Show
        Adrian Crum added a comment - - edited To make what I'm proposing clearer, I can use a simple example. An OFBiz developer wants to create a UI label for the word "second" and creates a UI label with the key "CommonSecond". In English, the word "second" has two meanings: ordinal and temporal (after first, and 1/60th of a minute). Since only one UI label exists, it is used for both meanings. But in other languages, they might be different words - so they require different UI label keys. A better approach would be to have two UI label keys: "CommonSecondOrdinal" and "CommonSecondTemporal". Both keys would be translated to English as "second" - but other languages would be free to use different words.
        Hide
        Martin Kaiser added a comment -

        Yes, this could be an improvement.

        But I think that this means also that no label key should be used twice, as in any language there could be a different meaning of it.

        Show
        Martin Kaiser added a comment - Yes, this could be an improvement. But I think that this means also that no label key should be used twice, as in any language there could be a different meaning of it.
        Hide
        Christian Geisert added a comment -

        Yeah, translation is hard (and an ongoing process..)

        But I think lables should only be splitted if there is a different meaning in any language.

        I'll commit your patch and then we can refine from there

        Show
        Christian Geisert added a comment - Yeah, translation is hard (and an ongoing process..) But I think lables should only be splitted if there is a different meaning in any language. I'll commit your patch and then we can refine from there
        Hide
        Christian Geisert added a comment -

        Patch committed (a few merges by hand and removed Tabs)

        Thanks for your contribution!

        Show
        Christian Geisert added a comment - Patch committed (a few merges by hand and removed Tabs) Thanks for your contribution!
        Christian Geisert made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Fix Version/s SVN trunk [ 12311928 ]
        Resolution Fixed [ 1 ]
        Jacques Le Roux made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Patch Available Patch Available
        5m 32s 1 Martin Kaiser 29/May/12 09:04
        Patch Available Patch Available Resolved Resolved
        30d 16m 1 Christian Geisert 28/Jun/12 09:21
        Resolved Resolved Closed Closed
        185d 2h 4m 1 Jacques Le Roux 30/Dec/12 10:25

          People

          • Assignee:
            Christian Geisert
            Reporter:
            Martin Kaiser
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development