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

Re: [pcgen_international] Syntax for Internationalization in Data Files

Expand Messages
  • 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 1 of 5 , Jan 22, 2007
      --- 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 2 of 5 , Jan 22, 2007
        --- 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 3 of 5 , Jan 22, 2007
          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 4 of 5 , Jan 27, 2007
            --- 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.