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

Re: [pcgen_international] PCGen 6.0 I18N Requirements Gathering

Expand Messages
  • boomer70
    Hi all, Good digging Tom :) ... By Constants you mean they are hardcoded in the code? Obviously these do need to be translated. You can also add some
    Message 1 of 11 , Jun 27, 2007
      Hi all,

      Good digging Tom :)

      --- Tom Parker <thpr@...> wrote:

      > Hi all,
      >
      > Since we don't seem to be digging up Aaron at the
      > moment, I wanted to
      > get this discussion (re-)started. I know many are
      > you are aware that
      > we have an Internationalization milestone set for
      > our PCGen 6.x
      > series. I would like to address this early because
      > I believe some of
      > the I18N implementation will also beneficial
      > elsewhere in the code, so
      > I want to make sure such structures are only built
      > once. (It will
      > also benefit implementing i18n early in the 6.x
      > cycle, so hopefully I
      > can get some good participation here)
      >
      > At the same time, since I can only stutter in a
      > foreign language (my 3
      > years of Spanish from grade school are pretty far in
      > the past), I want
      > to make sure we are hitting everything in the data
      > that needs to be
      > translated. I know some of you have tried to do
      > that, so I'm looking
      > to draw on your experience. (It's not that more
      > can't be added, I
      > would just like to dig up as much as we can as early
      > as possible, so
      > that appropriate options for performing I18N are
      > considered.)
      >
      > For now, I'm only concerned with the LST files - I
      > recognize the GUI
      > also needs translating, but that is a different
      > challenge I'd like to
      > handle at a different time.
      >
      > I also recognize that there is a need to have
      > translation occur
      > without having to constantly modify different files.
      > I want to come up
      > with a method that supports that requirement.
      >
      > Given that, here are the items that I believe need
      > translation:
      >
      > Ability/Feat "BENEFIT"
      > Alignment "ABB"
      > Deity "APPEARANCE", "PANTHEON", "SYMBOL", "TITLE",
      > "WORSHIPPERS"
      > Class "ABB"
      > Equipment "FUMBLERANGE", "QUALITY", "RATEOFFIRE",
      > "SPROP"
      > EqMod "FUMBLERANGE", "FORMATCAT", "NAMEOPT", "SPROP"
      > Global "DR" (for damage types), "FOLLOWERS" (to set
      > the follower
      > type), "OUTPUTNAME", REGION", "SA", "TEMPDESC",
      > "CHOOSE:STRING",
      > "CHOOSE:SA", "DESC"
      > Race "RACETYPE", "RACESUBTYPE",
      > Spell "CASTTIME", "COMPS", "DURATION", "RANGE",
      > "SAVEINFO",
      > "SPELLRES", "TARGETAREA", "VARIANTS"
      > Stat "ABB"
      > Template "REGION", "SUBREGION", "SUBRACE",
      > "RACETYPE", "RACESUBTYPE",
      > "NATURALATTACKS",
      >
      > Constants:
      >
      > Spell Descriptor
      > Spell School
      > Spell Sub School
      > Ability Categories (e.g. Feat, Mutation)
      > Movement types
      > Vision types
      > Genders

      By Constants you mean they are "hardcoded" in the
      code? Obviously these do need to be translated.

      You can also add some information that is stored in
      the various TYPE: tags. For example Fighter feats
      should be translated.

      >
      >
      > Note that PObjects include Alignment, Deities,
      > Domains, Classes
      > (including SubClasses & SubstitutionClasses),
      > Templates, Abilities,
      > Feats, Spells, Skills, Equipment, Equipment
      > Modifiers, Proficiencies,
      > Kits, Races, Sizes, and Stats.
      >
      Also includes CHECKS (saves).

      > Note also that their "display name" is controlled by
      > the "OUTPUTNAME"
      > token, so just general translation of an item like
      > "Fighter" is
      > considered part of that, for now.
      >

      I am not sure we really want to assume that OUTPUTNAME
      will be used for translation. Firstly, that would
      mean that either you would not see the translation in
      the GUI or you would have to set the "Use Output name"
      option (which I think only works for some things).

      I think since we are looking to gather requirements we
      shouldn't make any asumptions at this point.

      > Items I am unsure if they need to be translated
      > (need to check if
      > these are ever output to the user)
      >
      > Equipment Wield Types (e.g. "One Handed")
      Probably needs to be translated.

      > Load Names (e.g. Heavy)
      Should be translated.

      > Ability Natures (Normal, Automatic, Virtual)
      May not need to be translated (probably not).

      > Equipmen Natures (Normal, Automatic)
      See above.

      > Equipment "CONTAINS"
      Not sure what you mean here.
      >
      >
      > =====
      >
      > Once we take a pass or two at this, I will revisit
      > how we will
      > actually address translation and doing that without
      > having to
      > constantly rebuild LST files. I have some ideas,
      > but want to take
      > this one step at a time (some of those methods may
      > not work if I am
      > missing any tokens that need to be translated)
      >

      I think we were pretty close to coming to a consensus
      on this a while ago. I believe I made a post about
      how I would like to see it done a while ago. I will
      have to see if I can dig it up (can't access the
      groups at work).

      -Aaron


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



      ____________________________________________________________________________________
      Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
      http://answers.yahoo.com/dir/?link=list&sid=396545433
    • Alvise Nicoletti
      My proposal of using dinamically generated datasets (that can be done for example with php preceding the variables with a $ and taking the data from a
      Message 2 of 11 , Jun 27, 2007
        My proposal of using dinamically generated datasets (that can be done for
        example with php preceding the variables with a "$" and taking the data from
        a database) has been already posted in this mailing list months ago.

        However: Any way you will use to translate dinamically the dataset stuff, a
        dictionary database of meanings (not of words) is needed, or the work will
        have to be done again and again every time something changes.

        That's my point.

        2007/6/27, boomer70 <boomer70@...>:
        >
        > Hi all,
        >
        > Good digging Tom :)
        >
        >
        > --- Tom Parker <thpr@... <thpr%40yahoo.com>> wrote:
        >
        > > Hi all,
        > >
        > > Since we don't seem to be digging up Aaron at the
        > > moment, I wanted to
        > > get this discussion (re-)started. I know many are
        > > you are aware that
        > > we have an Internationalization milestone set for
        > > our PCGen 6.x
        > > series. I would like to address this early because
        > > I believe some of
        > > the I18N implementation will also beneficial
        > > elsewhere in the code, so
        > > I want to make sure such structures are only built
        > > once. (It will
        > > also benefit implementing i18n early in the 6.x
        > > cycle, so hopefully I
        > > can get some good participation here)
        > >
        > > At the same time, since I can only stutter in a
        > > foreign language (my 3
        > > years of Spanish from grade school are pretty far in
        > > the past), I want
        > > to make sure we are hitting everything in the data
        > > that needs to be
        > > translated. I know some of you have tried to do
        > > that, so I'm looking
        > > to draw on your experience. (It's not that more
        > > can't be added, I
        > > would just like to dig up as much as we can as early
        > > as possible, so
        > > that appropriate options for performing I18N are
        > > considered.)
        > >
        > > For now, I'm only concerned with the LST files - I
        > > recognize the GUI
        > > also needs translating, but that is a different
        > > challenge I'd like to
        > > handle at a different time.
        > >
        > > I also recognize that there is a need to have
        > > translation occur
        > > without having to constantly modify different files.
        > > I want to come up
        > > with a method that supports that requirement.
        > >
        > > Given that, here are the items that I believe need
        > > translation:
        > >
        > > Ability/Feat "BENEFIT"
        > > Alignment "ABB"
        > > Deity "APPEARANCE", "PANTHEON", "SYMBOL", "TITLE",
        > > "WORSHIPPERS"
        > > Class "ABB"
        > > Equipment "FUMBLERANGE", "QUALITY", "RATEOFFIRE",
        > > "SPROP"
        > > EqMod "FUMBLERANGE", "FORMATCAT", "NAMEOPT", "SPROP"
        > > Global "DR" (for damage types), "FOLLOWERS" (to set
        > > the follower
        > > type), "OUTPUTNAME", REGION", "SA", "TEMPDESC",
        > > "CHOOSE:STRING",
        > > "CHOOSE:SA", "DESC"
        > > Race "RACETYPE", "RACESUBTYPE",
        > > Spell "CASTTIME", "COMPS", "DURATION", "RANGE",
        > > "SAVEINFO",
        > > "SPELLRES", "TARGETAREA", "VARIANTS"
        > > Stat "ABB"
        > > Template "REGION", "SUBREGION", "SUBRACE",
        > > "RACETYPE", "RACESUBTYPE",
        > > "NATURALATTACKS",
        > >
        > > Constants:
        > >
        > > Spell Descriptor
        > > Spell School
        > > Spell Sub School
        > > Ability Categories (e.g. Feat, Mutation)
        > > Movement types
        > > Vision types
        > > Genders
        >
        > By Constants you mean they are "hardcoded" in the
        > code? Obviously these do need to be translated.
        >
        > You can also add some information that is stored in
        > the various TYPE: tags. For example Fighter feats
        > should be translated.
        >
        > >
        > >
        > > Note that PObjects include Alignment, Deities,
        > > Domains, Classes
        > > (including SubClasses & SubstitutionClasses),
        > > Templates, Abilities,
        > > Feats, Spells, Skills, Equipment, Equipment
        > > Modifiers, Proficiencies,
        > > Kits, Races, Sizes, and Stats.
        > >
        > Also includes CHECKS (saves).
        >
        > > Note also that their "display name" is controlled by
        > > the "OUTPUTNAME"
        > > token, so just general translation of an item like
        > > "Fighter" is
        > > considered part of that, for now.
        > >
        >
        > I am not sure we really want to assume that OUTPUTNAME
        > will be used for translation. Firstly, that would
        > mean that either you would not see the translation in
        > the GUI or you would have to set the "Use Output name"
        > option (which I think only works for some things).
        >
        > I think since we are looking to gather requirements we
        > shouldn't make any asumptions at this point.
        >
        > > Items I am unsure if they need to be translated
        > > (need to check if
        > > these are ever output to the user)
        > >
        > > Equipment Wield Types (e.g. "One Handed")
        > Probably needs to be translated.
        >
        > > Load Names (e.g. Heavy)
        > Should be translated.
        >
        > > Ability Natures (Normal, Automatic, Virtual)
        > May not need to be translated (probably not).
        >
        > > Equipmen Natures (Normal, Automatic)
        > See above.
        >
        > > Equipment "CONTAINS"
        > Not sure what you mean here.
        > >
        > >
        > > =====
        > >
        > > Once we take a pass or two at this, I will revisit
        > > how we will
        > > actually address translation and doing that without
        > > having to
        > > constantly rebuild LST files. I have some ideas,
        > > but want to take
        > > this one step at a time (some of those methods may
        > > not work if I am
        > > missing any tokens that need to be translated)
        > >
        >
        > I think we were pretty close to coming to a consensus
        > on this a while ago. I believe I made a post about
        > how I would like to see it done a while ago. I will
        > have to see if I can dig it up (can't access the
        > groups at work).
        >
        > -Aaron
        >
        > ----------------
        > Aaron Divinsky
        > PCGen Docs 2nd, Data Chimp, Code Chimp, Doc Tamarin
        >
        > __________________________________________________________
        > Be a better Heartthrob. Get better relationship answers from someone who
        > knows. Yahoo! Answers - Check it out.
        > http://answers.yahoo.com/dir/?link=list&sid=396545433
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Tom Parker
        Alvise Nicoletti wrote:However: Any way you will use to translate dinamically the dataset stuff, a dictionary database of meanings
        Message 3 of 11 , Jun 27, 2007
          Alvise Nicoletti <alvise.nicoletti@...> wrote:However: Any way you will use to translate dinamically the dataset stuff, a
          dictionary database of meanings (not of words) is needed, or the work will
          have to be done again and again every time something changes.

          I would like to understand the concern here, since translation could make me misinterpret the meaning you intend.

          I do not believe we can dynamically translate everything in the sense that we are not Babelfish. There will have to be some form of listing that X translates into Y. If a Skill changes from "Dodge" to "Get out of the Way", we can't expect a translation system to automatically make that update. (If we were doing that, we'd be building a translator, not a character generator)

          I *do* believe we should have the ability to:

          1) Define that Skill "Dodge" is actually "Detour" (or whatever it is in your local language).

          2) Have that translation should work in future versions of PCGen (meaning the translations are detached in some fashion from the rules & associations defined in the data files, so as the rules change, the translations work properly)

          3) Have the datasets and PCs language-independent enough that a PC could be built in an Italian instance of PCGen and displayed in a French instance and be displayed fully in French

          4) Be able to detect and report any items which were not provided a translation, but still fail gracefully back to the default (American English?)

          5) Be able to detect changes in the base language (effectively American English) between versions of PCGen to "flag" areas where translation may be required due to naming changes

          I believe those 5 items summarize how I would interpert "translate dynamically the dataset". Does that meet with the intent of your statement/concern?

          Thanks.

          TP.


          --
          Tom Parker
          thpr@... and tppublic@...

          ---------------------------------
          Expecting? Get great news right away with email Auto-Check.
          Try the Yahoo! Mail Beta.

          [Non-text portions of this message have been removed]
        • Tom Parker
          boomer70 wrote: Hi all, Hey! Good to hear from you By Constants you mean they are hardcoded in the code? Obviously these do need to be
          Message 4 of 11 , Jun 27, 2007
            boomer70 <boomer70@...> wrote: Hi all,

            Hey! Good to hear from you

            By Constants you mean they are "hardcoded" in the
            code? Obviously these do need to be translated.
            Something like that (although they aren't technically hardcoded, but dynamically built lists). By constants, I mean that in the CDOM branch they are actually typesafe constants in some fashion (see pcgen.cdom.enumeration)

            You can also add some information that is stored in
            the various TYPE: tags. For example Fighter feats
            should be translated.
            So the question here is whether the TYPE is ever actually output to the user. I'll have to go check, because I honestly don't recall a situation where that happens. Of course, that's probably not the only thing I missed.

            > Note that PObjects include...

            Also includes CHECKS (saves).
            Ah, yes, missed that.

            I am not sure we really want to assume that OUTPUTNAME
            will be used for translation.
            I think since we are looking to gather requirements we
            shouldn't make any asumptions at this point.
            Good point. I guess the intent would be to indicate that the base name of a PObject must also be translated, even though there isn't an associated "token" to go along with the primary name.

            > Equipment "CONTAINS"
            Not sure what you mean here.

            CONTAINS:100|Potion=10 (or whatever the syntax is)

            Does "Potion" need translation, or is it simply a rule. I'm unsure whether CONTAINS is ever output in human readable form, so that's why I was listing it as "unsure"



            --
            Tom Parker
            thpr@... and tppublic@...

            ---------------------------------
            Don't be flakey. Get Yahoo! Mail for Mobile and
            always stay connected to friends.

            [Non-text portions of this message have been removed]
          • Alvise Nicoletti
            ... Ok, and why should a skill change? We can t translate things if someone changes their names. WOTC don t write manual with skill ID as a primary key, but
            Message 5 of 11 , Jun 27, 2007
              > I do not believe we can dynamically translate everything in the sense that we are not
              > Babelfish. There will have to be some form of listing that X translates into Y. If a Skill
              > changes from "Dodge" to "Get out of the Way", we can't expect a translation system to
              > automatically make that update. (If we were doing that, we'd be building a translator, not
              > a character generator)

              Ok, and why should a skill change? We can't translate things if
              someone changes their names.

              WOTC don't write manual with "skill ID" as a primary key, but we can
              identify everything from the "common word" used for that thing.


              > I *do* believe we should have the ability to:
              >
              > 1) Define that Skill "Dodge" is actually "Detour" (or whatever it is in your local language).

              Thas is was I just wrote.

              >
              > 2) Have that translation should work in future versions of PCGen (meaning the translations are detached in some fashion from the rules & associations defined in the data files, so as the rules change, the translations work properly)

              Yes, and "abstracting" the dataset concept with a dictionary database
              is the only way you will do this, without doing yourself a dataset for
              every language.

              >
              > 3) Have the datasets and PCs language-independent enough that a PC could be built in an Italian instance of PCGen and displayed in a French instance and be displayed fully in French

              That depends on what PcGen load (datasets) and someone already told
              that the SOURCES translation is a different stuff between the IDE
              translation.

              If PcGen loads french datasets, the result will be in french for a
              viewer (of course if a "label" variable is defined for the objects)

              >
              > 4) Be able to detect and report any items which were not provided a translation, but still fail gracefully back to the default (American English?)
              >
              > 5) Be able to detect changes in the base language (effectively American English) between versions of PCGen to "flag" areas where translation may be required due to naming changes
              >
              > I believe those 5 items summarize how I would interpert "translate dynamically the dataset". Does that meet with the intent of your statement/concern?
              >
              > Thanks.
              >
              > TP.
              >
              > --
              > Tom Parker
              > thpr@... and tppublic@...
              >
              > ---------------------------------
              > Expecting? Get great news right away with email Auto-Check.
              > Try the Yahoo! Mail Beta.
              >
              > [Non-text portions of this message have been removed]
              >
              >
            • Tom Parker
              Alvise Nicoletti wrote:Ok, and why should a skill change? We can t translate things if someone changes their names. Well,
              Message 6 of 11 , Jun 27, 2007
                Alvise Nicoletti <alvise.nicoletti@...> wrote:Ok, and why should a skill change? We can't translate things if
                someone changes their names.
                Well, technically, you can, it just makes it really hard. The change is something that needs to be detected and handled.

                However, it's just an example. Things *shouldn't* change, but that doesn't mean one doesn't consider what happens in case it does change. I spent many years trying to break software, and some of my education was from a professor that programmed heart/lung machines, so I tend to be very methodical about considering "what ifs", even if they are unlikely to occur.
                > 2) Have that translation should work in future versions of PCGen (meaning the translations are detached in some fashion from the rules & associations defined in the data files, so as the rules change, the translations work properly)

                Yes, and "abstracting" the dataset concept with a dictionary database
                is the only way you will do this, without doing yourself a dataset for
                every language.
                I agree it needs to be abstracted, but there are multiple ways of implementing such a dictionary. Thus I am trying to ensure we are capturing the requirements, so that the system that is built meets the requirements.
                > 3) Have the datasets and PCs language-independent enough that a PC could be built in an Italian instance of PCGen and displayed in a French instance and be displayed fully in French

                That depends on what PcGen load (datasets) and someone already told
                that the SOURCES translation is a different stuff between the IDE
                translation.

                If PcGen loads french datasets, the result will be in french for a
                viewer (of course if a "label" variable is defined for the objects)
                Yes and no. If the datasets are properly built, then the datasets could use the same localization as the UI (or different localization if someone wanted preferences to do that). The point is that I shouldn't have to load French datasets to open a PC that was built with French datasets. I should be able to load the American English datasets and debug it in American English (or you could share an NPC with me and I could print it entirely in English). [Of course, internationalization items may not be debuggable like that, but non-i18n stuff would be]

                That's why I want to get the requirements properly stated - I do not believe that building datasets for each language is the answer, and I also don't want it to be simply creating multiple dependent datasets (which could be loaded separately) by applying a database to a master data file (because that prevents sharing characters across language boundaries).

                TP.


                --
                Tom Parker
                thpr@... and tppublic@...

                ---------------------------------
                Finding fabulous fares is fun.
                Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.

                [Non-text portions of this message have been removed]
              • Ludovic Fierville
                We have a not-so-bad solution right now, though it needs some polishing. IMHO, the best solution is to keep the master datasets in english, because the data
                Message 7 of 11 , Jun 27, 2007
                  We have a not-so-bad solution right now, though it needs some polishing.

                  IMHO, the best solution is to keep the "master" datasets in english,
                  because the data team is mainly english-speaking, and it's quite
                  fairly understood by RPG people (I think).

                  Keeping these datasets, we could create "translating" datasets in
                  which we would .MOD the existing elements. I actually created such a
                  (incomplete) set in french by using .MOD and adding an OUTPUTNAME in
                  french. Works quite well, though I detected some small bugs in the
                  UI, and the OS is still in english (for "hardcoded" parts).

                  I don't think creating whole translated datasets is a good idea. Even
                  by using an intermediate database as Alvise suggets, we would have to
                  recreate the sets each time a change is made (in the "original"
                  dataset or in the translating database).

                  OUTPUTNAME is not perfect, but it's not so bad. If we want to improve
                  it, we could create a new tag, for example TRANSLATE. This tag would
                  be used in the UI and on the OS, "replacing" the english name with
                  the translated one. The main point here is to let PCGen use the
                  english name internally, and only use the translated one where the
                  user can see the result.

                  What we would need :
                  - a translating file for the UI. Quite simple, there aren't much
                  translatings to do (some are actually done, though are hardcoded AFAIK)
                  - translatings datasets ; I have coded one (you can find it in the
                  Files section of this group), the datasets are loaded with the other
                  datasets and .MOD them as needed. We could add an option to tell
                  PCGen we want french or italian or esperanto or whatever and it would
                  load the necessary files (they would have to be put in a special place)

                  If we want to go all the way, we would need to partially translate
                  the docs, but I don't think we are ready for this tough cookie.

                  So, to summarize :
                  - a way to translate the UI, for example by using variables in the UI
                  code which would be replaced by values extracted from a file
                  - a way to translate dataset info that the end user can see

                  It seems natural to fall back to english if something fails to load
                  or is incomplete (lack of translating data -> use original data,
                  seems quite simple)

                  Tom, I think you have summarized the tags which would need a
                  translation. I'm not a coder, so I'm not sure if the list is
                  complete, but we could give it a try and complete the list while the
                  betas go.

                  Ludo


                  Le 27 juin 07 à 20:49, Tom Parker a écrit :

                  > Alvise Nicoletti <alvise.nicoletti@...> wrote:Ok, and why
                  > should a skill change? We can't translate things if
                  > someone changes their names.
                  > Well, technically, you can, it just makes it really hard. The
                  > change is something that needs to be detected and handled.
                  >
                  > However, it's just an example. Things *shouldn't* change, but that
                  > doesn't mean one doesn't consider what happens in case it does
                  > change. I spent many years trying to break software, and some of
                  > my education was from a professor that programmed heart/lung
                  > machines, so I tend to be very methodical about considering "what
                  > ifs", even if they are unlikely to occur.
                  >> 2) Have that translation should work in future versions of PCGen
                  >> (meaning the translations are detached in some fashion from the
                  >> rules & associations defined in the data files, so as the rules
                  >> change, the translations work properly)
                  >
                  > Yes, and "abstracting" the dataset concept with a dictionary database
                  > is the only way you will do this, without doing yourself a dataset for
                  > every language.
                  > I agree it needs to be abstracted, but there are multiple ways of
                  > implementing such a dictionary. Thus I am trying to ensure we are
                  > capturing the requirements, so that the system that is built meets
                  > the requirements.
                  >> 3) Have the datasets and PCs language-independent enough that a
                  >> PC could be built in an Italian instance of PCGen and displayed in
                  >> a French instance and be displayed fully in French
                  >
                  > That depends on what PcGen load (datasets) and someone already told
                  > that the SOURCES translation is a different stuff between the IDE
                  > translation.
                  >
                  > If PcGen loads french datasets, the result will be in french for a
                  > viewer (of course if a "label" variable is defined for the objects)
                  > Yes and no. If the datasets are properly built, then the datasets
                  > could use the same localization as the UI (or different
                  > localization if someone wanted preferences to do that). The point
                  > is that I shouldn't have to load French datasets to open a PC that
                  > was built with French datasets. I should be able to load the
                  > American English datasets and debug it in American English (or you
                  > could share an NPC with me and I could print it entirely in
                  > English). [Of course, internationalization items may not be
                  > debuggable like that, but non-i18n stuff would be]
                  >
                  > That's why I want to get the requirements properly stated - I do
                  > not believe that building datasets for each language is the answer,
                  > and I also don't want it to be simply creating multiple dependent
                  > datasets (which could be loaded separately) by applying a database
                  > to a master data file (because that prevents sharing characters
                  > across language boundaries).
                  >
                  > TP.
                  >
                  >
                  > --
                  > Tom Parker
                  > thpr@... and tppublic@...
                  >
                  > ---------------------------------
                  > Finding fabulous fares is fun.
                  > Let Yahoo! FareChase search your favorite travel sites to find
                  > flight and hotel bargains.
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >

                  Ludovic Fierville
                  lfierville<at>gmail<dot>com

                  ~ Tengoku de omachisi te imasu ~
                • Tom Parker
                  Ludovic Fierville wrote:IMHO, the best solution is to keep the master datasets in english, because the data team is mainly
                  Message 8 of 11 , Jun 27, 2007
                    Ludovic Fierville <lfierville@...> wrote:IMHO, the best solution is to keep the "master" datasets in english,
                    because the data team is mainly english-speaking, and it's quite
                    fairly understood by RPG people (I think).

                    I agree with that general concept.

                    Keeping these datasets, we could create "translating" datasets in
                    which we would .MOD the existing elements. I actually created such a
                    (incomplete) set in french by using .MOD and adding an OUTPUTNAME in
                    french. Works quite well, though I detected some small bugs in the
                    UI, and the OS is still in english (for "hardcoded" parts).

                    This works for some items, but will not work well for others. We need something with a bit more power than .MOD in order to handle things like Equipment Qualities, DESC tokens, and the Constants (e.g. Spell Schools). Given that, it probably makes sense to keep everything handled in a common fashion.

                    I don't think creating whole translated datasets is a good idea. Even
                    by using an intermediate database as Alvise suggets, we would have to
                    recreate the sets each time a change is made (in the "original"
                    dataset or in the translating database).

                    I agree. The "creation" should occur when the code imports the LST files into PCGen.

                    The main point here is to let PCGen use the
                    english name internally, and only use the translated one where the
                    user can see the result.

                    Something to that effect is my suspicion on how it will work (and what is currently in my mind), but I'm trying to validate requirements to ensure that will actually work :)





                    --
                    Tom Parker
                    thpr@... and tppublic@...

                    ---------------------------------
                    The fish are biting.
                    Get more visitors on your site using Yahoo! Search Marketing.

                    [Non-text portions of this message have been removed]
                  • Aubé Philippe
                    Hi all, I think we should bear in mind that : 1. All that is to be displayed should be translated. 2. Everything that is to be displayed should not be used
                    Message 9 of 11 , Jun 27, 2007
                      Hi all,

                      I think we should bear in mind that :

                      1. All that is to be displayed should be translated.
                      2. Everything that is to be displayed should not be used internally.
                      3. There should be as few files as possible and the link between initial
                      file and translation "holder" should be clear enough for everyone to be
                      able to modify the translation easily.
                      4. Changing tags should not affect the translation.
                      5. Sorting should take into account accents.

                      Let me be clearer on points 1 and 2.

                      Spells have an awful long list of factors, most need to be displayed AND
                      are used internally. There should be no such thing. The duration of a
                      spell should be in two ratings : the duration as used internally and the
                      duration as displayed. Am I clear ?

                      Maybe it would be a good idea to plit the files in several files : one
                      file holding internal information, another one holding displayed
                      information along with the translations (maybe one file per language).
                      Each new PCGen version should simply modify the "internal information"
                      part, not the translation one. When the translation doesn't exist, then
                      the english displayed information should be used.
                    • Tom Parker
                      ... That is why I m trying to gather a list of what needs to be displayed or output. While I can take a pass from what I see in the code and character sheets,
                      Message 10 of 11 , Jun 29, 2007
                        --- In pcgen_international@yahoogroups.com, Aubé Philippe
                        <tymophil@...> wrote:
                        > I think we should bear in mind that :
                        >
                        > 1. All that is to be displayed should be translated.

                        That is why I'm trying to gather a list of what needs to be displayed
                        or output. While I can take a pass from what I see in the code and
                        character sheets, an exhaustive code search is time consuming, and a
                        few more sets of eyes and some experience with translation isn't
                        experience I want to ignore.

                        > 2. Everything that is to be displayed should not be used internally.

                        I disagree. There are some items (such as height) that could be
                        stored internally in arbitrary units, but converted to meters or
                        feet/inches only when displayed. This would require a database of
                        translations for meter, etc., but is likely preferable to forcing each
                        locality to translate "2 meters" into their local dialect.

                        > 3. There should be as few files as possible and the link between
                        initial
                        > file and translation "holder" should be clear enough for everyone to be
                        > able to modify the translation easily.

                        ...while at the same time not creating so much confusion for someone
                        creating a custom dataset that they have to do contortions to get a
                        personal dataset in only their home language.

                        > 4. Changing tags should not affect the translation.

                        Agreed

                        > 5. Sorting should take into account accents.

                        A GUI and Output Sheet item, already FREQed, and outside the scope of
                        my current inquiry, but I agree.

                        > Let me be clearer on points 1 and 2.
                        >
                        > Spells have an awful long list of factors, most need to be displayed
                        AND
                        > are used internally. There should be no such thing. The duration of a
                        > spell should be in two ratings : the duration as used internally and
                        the
                        > duration as displayed. Am I clear ?

                        I get the point; however, many of the spells items at the moment are
                        just Strings, so this isn't a concern.

                        > Maybe it would be a good idea to plit the files in several files : one
                        > file holding internal information, another one holding displayed
                        > information along with the translations (maybe one file per language).
                        > Each new PCGen version should simply modify the "internal information"
                        > part, not the translation one. When the translation doesn't exist, then
                        > the english displayed information should be used.

                        I think this is a bad idea, because it makes simple home-brew data
                        unnecessarily complicated by introducing multiple files. I believe
                        there are alternative solutions that do not require this complexity.
                        I'll explain more once I get a chance to dig up Aaron's previous
                        suggestions and make sure I'm not missing anything.

                        TP.
                      Your message has been successfully submitted and would be delivered to recipients shortly.