Loading ...
Sorry, an error occurred while loading the content.

Syntax for Internationalization in Data Files

Expand Messages
  • Tom Parker
    So I spent the ski lift rides this morning thinking about this, because my skiing friends were being particularly boring today. I m going to start with my last
    Message 1 of 5 , Jan 21, 2007
    • 0 Attachment
      So I spent the ski lift rides this morning thinking about this,
      because my skiing friends were being particularly boring today.

      I'm going to start with my last thoughts on this, though it really
      doesn't matter all that much for what I thought of.

      Based on Ludo's and other's ideas, I had suggested something like:

      CLASS:Barbarian
      DISPLAY:str_Classes.Name.Barbarian=Barbarian

      French translation file :
      str_Classes.Name.Barbarian=Barbare

      What struck me this morning is this: str_Classes.Name.Barbarian is
      effectively creating yet another key to identify the Barbarian. Why
      are we using a separate key, when a key system is already defined
      within PCGen? This actually produces a problem, because if you perform:

      CLASS:Barbarian.COPY=MyBarb

      You all of a sudden end up with a problem: both have the DISPLAY
      str_Classes.Name.Barbarian assocaited with them. Therefore, we have
      introduced a contract that a DISPLAY must be provided for every COPY,
      regardless of whether the user wants Internationalization (defining
      whether the DISPLAY would be copied over to the new object or not is
      irrelevant to the fact that it must be (re)defined to work properly).
      That requirement stinks, IMHO.

      Seriously, every object in the PCGen environment has (or should have -
      I'm holding aside an issue with Spells that is being discussed on
      -dev) a unique key - this is generally either the display name or an
      explicit key.

      Why can't this be used to identify the object to have the output in a
      different language?

      The Class LST would therefore remain unchanged, and the translation
      file would be of the form:

      CLASS:Barbarian=Barbare

      Abilities would get a little more complicated:

      ABILITY:CATEGORY|AbilityName=NomDeCapacités

      Okay, this doesn't look like a traditional translation file (meaning a
      Properties File), but it's a heck of a lot less typing, and actually
      produces a smaller burden on the code (since it would not have to
      access a SettingsHandler every time it needed to display the name of a
      PObject)? It also avoids a contract on Data file producers.

      I'm almost sure this can be shot full of holes by Aaron, but am
      curious on others' thoughts...
    • boomer70
      ... Well actually I was thinking about something along these lines anyway. I don t think it is the best solution overall but I think it is probably the best
      Message 2 of 5 , Jan 22, 2007
      • 0 Attachment
        --- Tom Parker <thpr@...> wrote:

        >
        > So I spent the ski lift rides this morning thinking
        > about this,
        > because my skiing friends were being particularly
        > boring today.
        >
        > I'm going to start with my last thoughts on this,
        > though it really
        > doesn't matter all that much for what I thought of.
        >
        > Based on Ludo's and other's ideas, I had suggested
        > something like:
        >
        > CLASS:Barbarian
        > DISPLAY:str_Classes.Name.Barbarian=Barbarian
        >
        > French translation file :
        > str_Classes.Name.Barbarian=Barbare
        >
        > What struck me this morning is this:
        > str_Classes.Name.Barbarian is
        > effectively creating yet another key to identify the
        > Barbarian. Why
        > are we using a separate key, when a key system is
        > already defined
        > within PCGen? This actually produces a problem,
        > because if you perform:
        >
        > CLASS:Barbarian.COPY=MyBarb
        >
        > You all of a sudden end up with a problem: both have
        > the DISPLAY
        > str_Classes.Name.Barbarian assocaited with them.
        > Therefore, we have
        > introduced a contract that a DISPLAY must be
        > provided for every COPY,
        > regardless of whether the user wants
        > Internationalization (defining
        > whether the DISPLAY would be copied over to the new
        > object or not is
        > irrelevant to the fact that it must be (re)defined
        > to work properly).
        > That requirement stinks, IMHO.
        >
        > Seriously, every object in the PCGen environment has
        > (or should have -
        > I'm holding aside an issue with Spells that is being
        > discussed on
        > -dev) a unique key - this is generally either the
        > display name or an
        > explicit key.
        >
        > Why can't this be used to identify the object to
        > have the output in a
        > different language?
        >
        > The Class LST would therefore remain unchanged, and
        > the translation
        > file would be of the form:
        >
        > CLASS:Barbarian=Barbare
        >
        > Abilities would get a little more complicated:
        >
        > ABILITY:CATEGORY|AbilityName=NomDeCapacités
        >
        > Okay, this doesn't look like a traditional
        > translation file (meaning a
        > Properties File), but it's a heck of a lot less
        > typing, and actually
        > produces a smaller burden on the code (since it
        > would not have to
        > access a SettingsHandler every time it needed to
        > display the name of a
        > PObject)? It also avoids a contract on Data file
        > producers.
        >
        > I'm almost sure this can be shot full of holes by
        > Aaron, but am
        > curious on others' thoughts...
        >

        Well actually I was thinking about something along
        these lines anyway. I don't think it is the best
        solution overall but I think it is probably the best
        for PCGen.

        This solution will only work for the PObject name
        field at the moment however. Maybe we can come up
        with an extention that will work for everything.

        What we need is some way of distinguishing what sort
        of PObject the key refers to. Since PObject keys are
        not globally unique we need to know that the key
        refers to a class object and not a race. For class we
        have an existing LST syntax we could extend
        CLASS:Barbarian but for most other PObjects we don't
        have such a prefix.

        I can think of two different ways to deal with it.
        The first would be similar to how we deal with it in
        LST in general. That is, to have seperate files for
        each PObject type. This would work but we would
        likely need the PCC file to reference them or hardcode
        the relationship between the translation file and the
        original. Also this approach does little to handle
        the other field issue.

        The second is to have a single translation file with
        sections. You could either manage that with some sort
        of CLASS: type prefix, or my preference, use a section
        tag to identify objects within a group much like a
        Windoze INI file has sections. This has the added
        benefit that I think it would be easy to extend to
        other things that need translation besides the PObject
        name.

        So I would see a LST translation file looking
        something like:

        [CLASS]
        Barbarian=Barbare

        [RACE]
        Human=Human

        [SOURCE]
        RSRD=RSRD

        [MOVE]
        Walk=Walk

        etc.

        -Aaron


        ----------------
        Aaron Divinsky
        PCGen Docs 2nd, Data Chimp, Code Gibbon, Doc Tamarin



        ____________________________________________________________________________________
        Expecting? Get great news right away with email Auto-Check.
        Try the Yahoo! Mail Beta.
        http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
      • Tom Parker
        ... Extending this to other objects isn t hard. I mean, most of what is in the LST files is actually references to other PObjects. Very little is actually
        Message 3 of 5 , Jan 22, 2007
        • 0 Attachment
          --- In pcgen_international@yahoogroups.com, boomer70 <boomer70@...> wrote:
          > The second is to have a single translation file with
          > sections. You could either manage that with some sort
          > of CLASS: type prefix, or my preference, use a section
          > tag to identify objects within a group much like a
          > Windoze INI file has sections. This has the added
          > benefit that I think it would be easy to extend to
          > other things that need translation besides the PObject
          > name.

          Extending this to other objects isn't hard. I mean, most of what is
          in the LST files is actually references to other PObjects. Very
          little is actually text that requires translation. That which does
          require translation is generally 1:1 with an object.

          For example, say we want to modify the DESC that is attached to Alertness:

          ABILITY:CATEGORY=FEAT|Alertness|DESC=Blah Blah Blah

          The major items I see that really need modification are:
          DISPLAYNAME
          OUTPUTNAME
          SPROP
          DESC
          TEMPDESC
          *This assumes SAs go away and become Abilities with DESCs

          There are probably a few more items that are TextProperties,
          especially before your spell changes go through, but not that much.

          The first two could address fields, the last three objects. Now this
          may only work in CDOM, not in 5.11, since items aren't as clean in
          hierarchy today. It would also require that each translatable tag
          only appear once - not sure if we can reasonably make that limitation
          or not... needs to be investigated further.

          Of course, the sectioned document thing could work the same way, as
          the addressing really is just off the key, so it could just as easily be:

          [ABILITY]
          CATEGORY=FEAT|Alertness=Alterness
          CATEGORY=FEAT|Alertness|DESC=AlternessDescription

          I prefer using the prefix tag (even though it's more verbose), because
          it keeps the loader stateless (no need to know if it's modifying FEATs
          or CLASSes at any given moment).
        • Aubé Philippe
          We need also a way to translate the spells attributes (area of effect, duration, etc.). I know they are used by the system, but we cannot have something in
          Message 4 of 5 , Jan 22, 2007
          • 0 Attachment
            We need also a way to translate the spells attributes (area of effect,
            duration, etc.). I know they are used by the system, but we cannot have
            something in english to describe the effects and attributes of a spell.

            Now what about things such as saves abilities (STR, CON, WIS, etc.)
            names, saves names, sizes (Huge, small, tiny, etc.) ? Many informations
            outside the data sets need translation.

            Best regards.

            Philippe

            Tom Parker a écrit :
            >
            > --- In pcgen_international@yahoogroups.com
            > <mailto:pcgen_international%40yahoogroups.com>, boomer70
            > <boomer70@...> wrote:
            > > The second is to have a single translation file with
            > > sections. You could either manage that with some sort
            > > of CLASS: type prefix, or my preference, use a section
            > > tag to identify objects within a group much like a
            > > Windoze INI file has sections. This has the added
            > > benefit that I think it would be easy to extend to
            > > other things that need translation besides the PObject
            > > name.
            >
            > Extending this to other objects isn't hard. I mean, most of what is
            > in the LST files is actually references to other PObjects. Very
            > little is actually text that requires translation. That which does
            > require translation is generally 1:1 with an object.
            >
            > For example, say we want to modify the DESC that is attached to Alertness:
            >
            > ABILITY:CATEGORY=FEAT|Alertness|DESC=Blah Blah Blah
            >
            > The major items I see that really need modification are:
            > DISPLAYNAME
            > OUTPUTNAME
            > SPROP
            > DESC
            > TEMPDESC
            > *This assumes SAs go away and become Abilities with DESCs
            >
            > There are probably a few more items that are TextProperties,
            > especially before your spell changes go through, but not that much.
            >
            > The first two could address fields, the last three objects. Now this
            > may only work in CDOM, not in 5.11, since items aren't as clean in
            > hierarchy today. It would also require that each translatable tag
            > only appear once - not sure if we can reasonably make that limitation
            > or not... needs to be investigated further.
            >
            > Of course, the sectioned document thing could work the same way, as
            > the addressing really is just off the key, so it could just as easily be:
            >
            > [ABILITY]
            > CATEGORY=FEAT|Alertness=Alterness
            > CATEGORY=FEAT|Alertness|DESC=AlternessDescription
            >
            > I prefer using the prefix tag (even though it's more verbose), because
            > it keeps the loader stateless (no need to know if it's modifying FEATs
            > or CLASSes at any given moment).
            >
            >
            > ------------------------------------------------------------------------
            >
            > No virus found in this incoming message.
            > Checked by AVG Free Edition.
            > Version: 7.1.410 / Virus Database: 268.17.4/644 - Release Date: 22/01/2007
            >
          • Tom Parker
            ... Spells are a whole different story at the moment due to the pending Spells addition (see the Wiki)... I left that out because I can t predict completely
            Message 5 of 5 , Jan 27, 2007
            • 0 Attachment
              --- In pcgen_international@yahoogroups.com, Aubé Philippe
              <tymophil@...> wrote:
              > We need also a way to translate the spells attributes (area of effect,
              > duration, etc.). I know they are used by the system, but we cannot have
              > something in english to describe the effects and attributes of a spell.

              Spells are a whole different story at the moment due to the pending
              Spells addition (see the Wiki)... I left that out because I can't
              predict completely what it will look like :)

              > Now what about things such as saves abilities (STR, CON, WIS, etc.)
              > names, saves names, sizes (Huge, small, tiny, etc.) ? Many informations
              > outside the data sets need translation.

              So PCStat's can be addressed as well, since they are also PObjects:

              PCSTAT:Strength=TranslatedText

              I agree the Abbreviations will also need fixing, I missed that in my
              earlier 'address' list.

              PCSTAT:Strength|ABB=FAS

              Sizes, Movements, etc. are enumerations, and would also require some
              form of translation - since they are unique items and do not need
              sub-addressing, I didn't consider those a major problem. I'm working
              at a high level at the moment, this will have to get more detailed as
              it progresses...
            Your message has been successfully submitted and would be delivered to recipients shortly.