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

XLIFF Support

Expand Messages
  • Yves Savourel
    Hi, I was trying version 1.6 RC5 to see how it was working with XLIFF documents, and while my test files load and can be translated without issue, I had to
    Message 1 of 28 , Jan 1, 2006
    • 0 Attachment
      Hi,

      I was trying version 1.6 RC5 to see how it was working with XLIFF
      documents, and while my test files load and can be translated without
      issue, I had to skip most elements, including the <source> content,
      and the <target> tags were part of the content (therefore getting in
      the TM, and making it not really useable outside OT.

      I'm guessing OT simply does not have a specific support for XLIFF. Is
      that somewhere in the roadmap?

      Thanks
      -yves
    • JC Helary
      ... OmegaT is not specifically tailored to be a xliff editor. Basically source files are monolingual files. Their whole structure copied and the translation is
      Message 2 of 28 , Jan 1, 2006
      • 0 Attachment
        > I was trying version 1.6 RC5 to see how it was working with XLIFF
        > documents, and while my test files load and can be translated without
        > issue, I had to skip most elements, including the <source> content,
        > and the <target> tags were part of the content (therefore getting in
        > the TM, and making it not really useable outside OT.

        OmegaT is not specifically tailored to be a xliff editor. Basically
        source files are monolingual files. Their whole structure copied and
        the translation is "injected" inside to create the target files.
        Which basically makes it difficult to handle bilingual files.

        > I'm guessing OT simply does not have a specific support for XLIFF. Is
        > that somewhere in the roadmap?

        We have been wishing that for a while. If you feel like taking a look
        at the dev list archives it is at:
        http://sourceforge.net/mailarchive/forum.php?forum_id=40737

        If xliff were to be supported that would allow us to also work with
        po and wg (the Apple bilingual format).

        Of course, since the code is open you can always play with it
        yourself and tell us what you think.

        A Happy new year !

        Jean-Christophe
      • Yves Savourel
        Hi Jean-Christophe, ... It would be nice to have a minimal monolingual support for XLIFF: only translating things between . That would assume the XLIFF
        Message 3 of 28 , Jan 1, 2006
        • 0 Attachment
          Hi Jean-Christophe,

          > OmegaT is not specifically tailored to be a xliff editor.
          > Basically source files are monolingual files. Their whole
          > structure copied and the translation is "injected" inside
          > to create the target files.
          > Which basically makes it difficult to handle bilingual files.

          It would be nice to have a minimal monolingual support for XLIFF: only translating things between <target>. That would assume the
          XLIFF documents have already their <target> filled with the text to translate. But that is often the case. It would be better than
          nothing.


          >> I'm guessing OT simply does not have a specific support for XLIFF. Is
          >> that somewhere in the roadmap?
          > We have been wishing that for a while. If you feel like taking a look at
          > the dev list archives it is at:
          > http://sourceforge.net/mailarchive/forum.php?forum_id=40737
          > If xliff were to be supported that would allow us to also work with po
          > and wg (the Apple bilingual format).
          > Of course, since the code is open you can always play with it
          > yourself and tell us what you think.

          Looking briefly at the code, the XMLAbstractFilter.java seems to provide an easy way to derive a basic XLIFFFilter class, like for
          OO. But I'm afraid I don't have the time to do anything more than look.

          Cheers,
          -yves
        • JC Helary
          ... Yves, thank you for your suggestions. It was considered to have a process fill automatically the target field, or to create an intermediate file with
          Message 4 of 28 , Jan 2, 2006
          • 0 Attachment
            >> OmegaT is not specifically tailored to be a xliff editor.
            >> Basically source files are monolingual files. Their whole
            >> structure copied and the translation is "injected" inside
            >> to create the target files.
            >> Which basically makes it difficult to handle bilingual files.
            >
            > It would be nice to have a minimal monolingual support for XLIFF:
            > only translating things between <target>. That would assume the
            > XLIFF documents have already their <target> filled with the text to
            > translate. But that is often the case. It would be better than
            > nothing.

            Yves, thank you for your suggestions.

            It was considered to have a process fill automatically the "target"
            field, or to create an intermediate file with this target value
            etc... I have no idea what the code looks like so I can't say what is
            more practical right now. But the actual roadmap for 2.0 is to move
            the core of OmegaT to a natively xml supporting process, unlike what
            it is at the present time: a "simple" text string engine.

            I have no doubt that shifting to native xml support will open new
            possibilities to other source formats handling. If partial/minimal
            xliff support can be accomplished with a few hacks in the current
            framework maybe it is worth taking a look. But do you think people
            would consider using OmegaT with a half baked xliff support when
            there are already very good xliff editors in the open source wild ?

            > Looking briefly at the code, the XMLAbstractFilter.java seems to
            > provide an easy way to derive a basic XLIFFFilter class, like for
            > OO. But I'm afraid I don't have the time to do anything more than
            > look.

            Henry has worked a lot on full tmx support in RC5 (it is being fine-
            tuned right now) so I am sure he'll take notice and check what the
            possibilities are, we happen to have discussed that right before
            Christmas on and off (dev) list.

            I wanted to keep him busy with better OOo support :) But since you
            insist maybe that's another RFE he will want to deal with with before
            we focus on OOo betterment.

            Meanwhile, keep on looking and suggesting if you have time, I don't
            think this group has ever been a "give the code or shut up" group :)

            Jean-Christophe
          • Martin Wunderlich
            Hi JC and Yves, ... In conjuntion with an article I recently wrote, I implemented something like this. It s an XLIFF pre-processor and available under GPL (see
            Message 5 of 28 , Jan 2, 2006
            • 0 Attachment
              Hi JC and Yves,

              > It was considered to have a process fill automatically the "target"
              > field, or to create an intermediate file with this target value
              > etc... I have no idea what the code looks like so I can't say what is
              > more practical right now.

              In conjuntion with an article I recently wrote, I implemented
              something like this. It's an XLIFF pre-processor and available under
              GPL (see "XLIFFPreparator" in the download section of
              www.martinwunderlich.com).

              Unfortunately, it uses XPath, which is not available for
              OmegaT at the moment as a restriction due to the use of Java 1.4.
              Perhaps we can integrate this in OmegaT 2.0. IIRC, Maxym had the plan
              to move to Java 1.5 for OmegaT 2.0.

              All the best,

              Martin
              --
              ----------------------------------------
              Martin Wunderlich, M.A.
              Translation/Localisation EN <-> DE

              www.martinwunderlich.com
              ----------------------------------------
              Free and open source software
              for translation/localisation:
              www.martinwunderlich.com/foss-links.html
              ----------------------------------------
              Random quote:
              "A shprakh iz a diyalekt mit an armey un a flot."
              "A language is a dialect with an army and a flot."
              - Max Weinreich
            • Henry Pijffers
              ... Already did so :) ... These 2 might actually need similar code, if not partially the same. Henry
              Message 6 of 28 , Jan 2, 2006
              • 0 Attachment
                JC Helary wrote:
                >
                > Yves wrote:
                >
                >> Looking briefly at the code, the XMLAbstractFilter.java seems to
                >> provide an easy way to derive a basic XLIFFFilter class, like for
                >> OO. But I'm afraid I don't have the time to do anything more than
                >> look.
                >
                > Henry has worked a lot on full tmx support in RC5 (it is being fine-
                > tuned right now) so I am sure he'll take notice and check what the
                > possibilities are
                >
                Already did so :)

                > I wanted to keep him busy with better OOo support :) But since you
                > insist maybe that's another RFE he will want to deal with with before
                > we focus on OOo betterment.
                >
                These 2 might actually need similar code, if not partially the same.

                Henry
              • Henry Pijffers
                ... Martin, what exactly are you using XPath for? Is it difficult or a lot of work to implement it using strictly Java 1.4 API? Henry
                Message 7 of 28 , Jan 2, 2006
                • 0 Attachment
                  Martin Wunderlich wrote:
                  >
                  > Unfortunately, it uses XPath, which is not available for
                  > OmegaT at the moment as a restriction due to the use of Java 1.4.
                  >
                  Martin, what exactly are you using XPath for? Is it difficult or a lot
                  of work to implement it using strictly Java 1.4 API?

                  Henry
                • JC Helary
                  ... Martin, If my memory serves me well, it was decided to keep Java 1.4 since even if OSX gets a end-user default version of 1.5, the OSX user base will not
                  Message 8 of 28 , Jan 2, 2006
                  • 0 Attachment
                    > Unfortunately, it uses XPath, which is not available for
                    > OmegaT at the moment as a restriction due to the use of Java 1.4.
                    > Perhaps we can integrate this in OmegaT 2.0. IIRC, Maxym had the plan
                    > to move to Java 1.5 for OmegaT 2.0.

                    Martin,

                    If my memory serves me well, it was decided to keep Java 1.4 since
                    even if OSX gets a end-user default version of 1.5, the OSX user base
                    will not likely shift to that version of the OS before a while,
                    especially since it will probably coincide with the Mac shift to
                    Intel cpus.

                    So right now I think only a Java 1.4.2 hack is possible...

                    JC
                  • Yves Savourel
                    ... Great! On a side note about XML and translation: A possible way to look at how to decide what is translatable or not in XML documents could be to implement
                    Message 9 of 28 , Jan 2, 2006
                    • 0 Attachment
                      > But the actual roadmap for 2.0 is to move the core of OmegaT to
                      > a natively xml supporting process, unlike what it is at the
                      > present time: a "simple" text string engine.

                      Great! On a side note about XML and translation: A possible way to look at how to decide what is translatable or not in XML
                      documents could be to implement W3C's ITS, especially the "Translatability" part: It's only at a first draft stage but it could
                      help. Also, it's an opportunity for the OmagaT dev team to comment and point out possible issues with ITS, and make it more friendly
                      to tools :)
                      The latest draft is here:
                      http://www.w3.org/TR/its/
                      And the current "issue list is here:
                      http://www.w3.org/Bugs/Public/buglist.cgi?query_format=&product=ITS


                      > I have no doubt that shifting to native xml support will open
                      > new possibilities to other source formats handling. If partial/minimal
                      > xliff support can be accomplished with a few hacks in the current
                      > framework maybe it is worth taking a look. But do you think people
                      > would consider using OmegaT with a half baked xliff support when
                      > there are already very good xliff editors in the open source wild ?

                      Actually there are not so many open-source XLIFF editors...

                      - KBabel provides only a very limited support.

                      - Sun's Open Language Tools as a pretty good support but for XLIFF 1.0 only

                      - Transolution... Maybe(?) but that tool requires so many other components that I have not made the effort to install it (as I
                      suspect many other potential users on Windows).

                      - others?

                      Yes, there are many tools that extract/merge to XLIFF files, but not so many editors.

                      Cheers,
                      -yves
                    • Martin Wunderlich
                      Hi Henry, ... I just had a look. The only place where I did use xpath is a method with the following signature: public NodeList getChildrenByTagName(Node
                      Message 10 of 28 , Jan 2, 2006
                      • 0 Attachment
                        Hi Henry,

                        > Martin, what exactly are you using XPath for? Is it difficult or a lot
                        > of work to implement it using strictly Java 1.4 API?

                        > Henry

                        I just had a look. The only place where I did use xpath is a method
                        with the following signature:

                        public NodeList getChildrenByTagName(Node parent, String tagname)

                        It would probably be no problem to do the same thing with the standard
                        xml libraries from org.w3c.dom.* and javax.xml.*.

                        Cheers,

                        Martin
                      • Martin Wunderlich
                        Hi JC ... Right, I do have a faint memory of some issues with Mac OSX. The problem was that 1.5 was linked to a paid upgrade to OS 10.4 or something. Cheers,
                        Message 11 of 28 , Jan 2, 2006
                        • 0 Attachment
                          Hi JC

                          > If my memory serves me well, it was decided to keep Java 1.4 since
                          > even if OSX gets a end-user default version of 1.5, the OSX user base
                          > will not likely shift to that version of the OS before a while,
                          > especially since it will probably coincide with the Mac shift to
                          > Intel cpus.

                          Right, I do have a faint memory of some issues with Mac OSX. The
                          problem was that 1.5 was linked to a paid upgrade to OS 10.4
                          or something.

                          Cheers,

                          Maritn
                        • JC Helary
                          ... Java 1.5 is available from Apple with no hacks only on OSX 10.4 Now, it does happen that there are simple hacks that allow for its installation on 10.3 :)
                          Message 12 of 28 , Jan 2, 2006
                          • 0 Attachment
                            > Right, I do have a faint memory of some issues with Mac OSX. The
                            > problem was that 1.5 was linked to a paid upgrade to OS 10.4
                            > or something.

                            :) That's a way of saying things :)

                            Java 1.5 is available from Apple with no hacks only on OSX 10.4

                            Now, it does happen that there are simple hacks that allow for its
                            installation on 10.3 :)
                            But that is not something I would recommend to normal users, although
                            it is not hard to implement.

                            If you want to try it I think the hack was described on MacOSXHints a
                            little while ago. But a google search should bring you the exact link.

                            JC
                          • JC Helary
                            ... Although they are still [todo] items, it just happens that I send an mail on the OD xml list a while ago to know if they were working on a
                            Message 13 of 28 , Jan 2, 2006
                            • 0 Attachment
                              > Great! On a side note about XML and translation: A possible way to
                              > look at how to decide what is translatable or not in XML
                              > documents could be to implement W3C's ITS, especially the
                              > "Translatability" part: It's only at a first draft stage but it could
                              > help. Also, it's an opportunity for the OmagaT dev team to comment
                              > and point out possible issues with ITS, and make it more friendly
                              > to tools :)
                              > The latest draft is here:
                              > http://www.w3.org/TR/its/

                              I liked the part:

                              > In addition, implementations as fixed modularizations of various
                              > existing vocabularies (e.g. XHTML [XHTML 1.0], DocBook [DocBook],
                              > Open Document [OpenDocument]) are provided.

                              Although they are still [todo] items, it just happens that I send an
                              mail on the OD xml list a while ago to know if they were working on a
                              "translatability" framework so that we could implement that in
                              OmegaT. It looks like they are not since I got no answer (or maybe I
                              was not clear enough in my inquiry).

                              > Actually there are not so many open-source XLIFF editors...
                              >
                              > - KBabel provides only a very limited support.
                              >
                              > - Sun's Open Language Tools as a pretty good support but for XLIFF
                              > 1.0 only
                              >
                              > - Transolution... Maybe(?) but that tool requires so many other
                              > components that I have not made the effort to install it (as I
                              > suspect many other potential users on Windows).
                              >
                              > - others?

                              You must be right. There was actually a similar question on debian
                              i18n right before xmas and the list of available "flos" tools was
                              pretty much limited to what you wrote above.

                              I suppose having xliff supported in OmegaT would make more sense with
                              that in mind (especially if that comes with the same level of po
                              support). I was discussing with the LocFactoryEditor developer the
                              other day and we agreed that having 3 different tools for localizing
                              _one_ application (one for wg/xliff/po GUI files, one for html, one
                              for rtf->in an OSX context) was _not_ the ideal situation.

                              OmegaT's strong point is that it seems to already have quite a strong
                              user base in the translation world, and giving it the few keys
                              necessary to open the flos (but not only) localisation world would
                              greatly improve its visibility, besides for attracting people in need
                              of a user friendly (?) xliff editor.

                              JC

                              ps: the thing is that right now even though tmx files are supposedly
                              fully supported by OmegaT, the tmx functions are mostly not
                              implemented in OmegaT. Similarly, if a xliff hack were to be
                              implemented, I am not sure the support level would be much higher
                              than what kbabel proposes now...

                              ps2: I just checked kbabel and saw that it is possible to open a
                              xliff file but could not find anything in the user manual. Only this
                              mail in September:

                              > I spent the following two weeks digging into the XLIFF specification,
                              > and looking at how we could redesign KBabel's Catalog class to model
                              > the hierarchical and rich XLIFF format as opposed to the
                              > string-table-like PO format. During the porting to Qt4, I realized
                              > that trying to refactor the Catalog to model XLIFF was going to be
                              > very hard, as basically everything in KBabel depends on the PO data
                              > model. So I decided to create a new library, libkbxliff, modelling the
                              > XLIFF specification as closely as possible. To summarize the model:

                              http://mail.kde.org/pipermail/kde-soc/2005-September/000162.html

                              So it looks like _not_ coming from a po background we could actually
                              implement something slightly better than what they have ?!?!?
                            • Henry Pijffers
                              ... To get a list of all sub elements with a certain tag name, you can call getElementsByTagName (in class Element). If you really only want direct children,
                              Message 14 of 28 , Jan 2, 2006
                              • 0 Attachment
                                Martin Wunderlich wrote:
                                >
                                > I just had a look. The only place where I did use xpath is a method
                                > with the following signature:
                                >
                                > public NodeList getChildrenByTagName(Node parent, String tagname)
                                >
                                > It would probably be no problem to do the same thing with the standard
                                > xml libraries from org.w3c.dom.* and javax.xml.*.
                                >
                                To get a list of all sub elements with a certain tag name, you can call
                                getElementsByTagName (in class Element). If you really only want direct
                                children, you can call getChildNodes (in class Node), and check each
                                node in that list, see if it's an element with the requested tag name.

                                Is this also the reason why XPath is needed for your SRX implementation?
                                If so, it could be easily modified as I wrote above, so we don't need to
                                include Apache libs in the distribution.

                                Henry
                              • Henry Pijffers
                                ... JC, this is what I was talking about earlier. I think it d be useful to implement this for OmegaT, instead of making up our own version of translatable
                                Message 15 of 28 , Jan 2, 2006
                                • 0 Attachment
                                  Yves Savourel wrote:
                                  >
                                  > Great! On a side note about XML and translation: A possible way to look at how to decide what is translatable or not in XML
                                  > documents could be to implement W3C's ITS, especially the "Translatability" part: It's only at a first draft stage but it could
                                  > help. Also, it's an opportunity for the OmagaT dev team to comment and point out possible issues with ITS, and make it more friendly
                                  > to tools :)
                                  > The latest draft is here:
                                  > http://www.w3.org/TR/its/
                                  >
                                  JC, this is what I was talking about earlier. I think it'd be useful to
                                  implement this for OmegaT, instead of making up our own version of
                                  "translatable items lists".

                                  Henry
                                • JC Helary
                                  ... My understanding is that the ITS is meant to propose meta info to xml based standards for translatable data specification. It does not actually specify
                                  Message 16 of 28 , Jan 2, 2006
                                  • 0 Attachment
                                    >> The latest draft is here:
                                    >> http://www.w3.org/TR/its/
                                    >>
                                    > JC, this is what I was talking about earlier. I think it'd be
                                    > useful to
                                    > implement this for OmegaT, instead of making up our own version of
                                    > "translatable items lists".

                                    My understanding is that the ITS is meant to propose meta info to xml
                                    based standards for translatable data specification. It does not
                                    actually specify which container are generally meant to contain
                                    possibly translatable strings.

                                    So if my understanding is correct, we still need to get an idea of
                                    where can the translatable strings be found in the xml structure
                                    before we actually worry about whether the strings are translatable
                                    or not. The first part is based on the format structure, and we need
                                    to get that correctly, the second on the "client"'s request and that
                                    would be implemented with ITS.


                                    JC
                                  • Martin Wunderlich
                                    Hi Henry, ... When I started working on the SRX implementation, I was smarter (or so I thought) and made extensive use of XPath. It does save a lot of work. In
                                    Message 17 of 28 , Jan 2, 2006
                                    • 0 Attachment
                                      Hi Henry,

                                      > Is this also the reason why XPath is needed for your SRX implementation?
                                      > If so, it could be easily modified as I wrote above, so we don't need to
                                      > include Apache libs in the distribution.

                                      When I started working on the SRX implementation, I was smarter (or so
                                      I thought) and made extensive use of XPath. It does save a lot of
                                      work. In order to rewrite the SRX code without
                                      XPath, I guess you'd have to do a lot of recursive processing and stuff like that.

                                      Cheers,

                                      Martin
                                    • Yves Savourel
                                      ... Correct. ... Mmmm... I think I understand, but correct me if not. Knowing the translatable parts and knowing if the client wants these parts to be
                                      Message 18 of 28 , Jan 2, 2006
                                      • 0 Attachment
                                        >>> The latest draft is here:
                                        >>> http://www.w3.org/TR/its/
                                        >>>
                                        >> JC, this is what I was talking about earlier. I think it'd be useful
                                        >> to implement this for OmegaT, instead of making up our own version of
                                        >> "translatable items lists".
                                        >
                                        > My understanding is that the ITS is meant to propose meta info to
                                        > xml based standards for translatable data specification. It does not
                                        > actually specify which container are generally meant to contain possibly
                                        > translatable strings.

                                        Correct.

                                        > So if my understanding is correct, we still need to get an idea of
                                        > where can the translatable strings be found in the xml structure before
                                        > we actually worry about whether the strings are translatable or not.
                                        > The first part is based on the format structure, and we need to get
                                        > that correctly, the second on the "client"'s request and that would be
                                        > implemented with ITS.

                                        Mmmm... I think I understand, but correct me if not.
                                        Knowing the translatable parts and knowing if the client wants these parts to be translated can be both addressed with ITS:

                                        You can have "dislocated" rules (at the top of the file, or in a separate file for example) that can list all the translatable
                                        elements, and you can have, within the document itself, indicators that override that information. The first rules would be like the
                                        "translatable items lists" Henry is referring to, the second set of metatdata would be things authors could put at specific places
                                        in the documents. You would have something like:

                                        ITS file (to apply to all files of type "myDoc"):
                                        <documentRules xmlns="http://www.w3.org/2005/11/its">
                                        <documentRule translateScope="//data" translate="no"/>
                                        <documentRule translateScope="//data" translate="yes"/>
                                        </documentRules>

                                        One of the XML file to translate:
                                        <myDoc xmlns="myDocument" xmlns:its="http://www.w3.org/2005/11/its">
                                        <data>No to translate</data>
                                        <text>To translate</text>
                                        <text its:translate="no">Exceptionally not to translate</text>
                                        </myDoc>

                                        Since ITS is a namespace, one could use it within it own XML format (for example, OmegaT's "translatable items lists").

                                        By the way, ITS does use XPath expressions... Actually the DOM selectNodes() method is probably what is needed: hopefully this is
                                        implemented in Java 1.4. If not, maybe something like dom4j could be used...

                                        -ys
                                      • Yves Savourel
                                        ... Oops... I meant correct for the first sentence. Incorrect for the second. -ys
                                        Message 19 of 28 , Jan 2, 2006
                                        • 0 Attachment
                                          >> My understanding is that the ITS is meant to propose meta info to xml
                                          >> based standards for translatable data specification. It does not
                                          >> actually specify which container are generally meant to contain
                                          >> possibly translatable strings.
                                          >
                                          > Correct.

                                          Oops... I meant correct for the first sentence. Incorrect for the second.

                                          -ys
                                        • JC Helary
                                          ... I think I got the whole point anyway. I m glad Learning XML is going to find practical usages ;) Thank you for pointing that to us ! JC ps: way past bed
                                          Message 20 of 28 , Jan 2, 2006
                                          • 0 Attachment
                                            >> Correct.
                                            >
                                            > Oops... I meant correct for the first sentence. Incorrect for the
                                            > second.

                                            I think I got the whole point anyway. I'm glad "Learning XML" is
                                            going to find practical usages ;)

                                            Thank you for pointing that to us !

                                            JC

                                            ps: way past bed time, a few segments for my deadline and I'm off the
                                            machine...
                                          • JC Helary
                                            ... Do you mean: ? ... JC
                                            Message 21 of 28 , Jan 2, 2006
                                            • 0 Attachment
                                              > ITS file (to apply to all files of type "myDoc"):
                                              > <documentRules xmlns="http://www.w3.org/2005/11/its">
                                              > <documentRule translateScope="//data" translate="no"/>
                                              > <documentRule translateScope="//data" translate="yes"/>
                                              > </documentRules>

                                              Do you mean:

                                              <documentRule translateScope="//text" translate="yes"/>

                                              ?


                                              > One of the XML file to translate:
                                              > <myDoc xmlns="myDocument" xmlns:its="http://www.w3.org/2005/11/its">
                                              > <data>No to translate</data>
                                              > <text>To translate</text>
                                              > <text its:translate="no">Exceptionally not to translate</text>
                                              > </myDoc>

                                              JC
                                            • Yves Savourel
                                              ... Yes. (Sorry: forgot to fix the copy+paste) I guess I need to turn off the machine too... -yves
                                              Message 22 of 28 , Jan 2, 2006
                                              • 0 Attachment
                                                >> ITS file (to apply to all files of type "myDoc"):
                                                >> <documentRules xmlns="http://www.w3.org/2005/11/its">
                                                >> <documentRule translateScope="//data" translate="no"/>
                                                >> <documentRule translateScope="//data" translate="yes"/>
                                                > </documentRules>
                                                >
                                                > Do you mean:
                                                >
                                                > <documentRule translateScope="//text" translate="yes"/>

                                                Yes. (Sorry: forgot to fix the copy+paste)
                                                I guess I need to turn off the machine too...

                                                -yves
                                              • Henry Pijffers
                                                ... From what I understood, ITS has 2 ways of telling us what bits are translatable: 1) By adding the attribute its:translate to an element that contains
                                                Message 23 of 28 , Jan 2, 2006
                                                • 0 Attachment
                                                  JC Helary wrote:
                                                  >
                                                  >>> The latest draft is here:
                                                  >>> http://www.w3.org/TR/its/
                                                  >>>
                                                  >> JC, this is what I was talking about earlier. I think it'd be
                                                  >> useful to
                                                  >> implement this for OmegaT, instead of making up our own version of
                                                  >> "translatable items lists".
                                                  >
                                                  > My understanding is that the ITS is meant to propose meta info to xml
                                                  > based standards for translatable data specification. It does not
                                                  > actually specify which container are generally meant to contain
                                                  > possibly translatable strings.
                                                  >
                                                  From what I understood, ITS has 2 ways of telling us what bits are
                                                  translatable:

                                                  1) By adding the attribute its:translate to an element that contains
                                                  translatable content, for example <p its:translate="yes">blablabla</p>

                                                  2) By adding tags/attributes to an XML schema for the document format in
                                                  question.

                                                  I don't think 1) will be of much concern, but 2) can be quite interesting.

                                                  > So if my understanding is correct, we still need to get an idea of
                                                  > where can the translatable strings be found in the xml structure
                                                  >
                                                  That's what 2) does. It can specify, for example, that the contents of a
                                                  <title> in a <head> are translatable.

                                                  Henry
                                                • Yves Savourel
                                                  Hi Henry, ... And 3) by adding a set of dislocated rules in a separate standalone file, or somewhere in a document instance. This for example to work with
                                                  Message 24 of 28 , Jan 2, 2006
                                                  • 0 Attachment
                                                    Hi Henry,

                                                    > From what I understood, ITS has 2 ways of telling us what bits are
                                                    > translatable:
                                                    >
                                                    > 1) By adding the attribute its:translate to an element that
                                                    > contains translatable content, for example <p its:translate="yes">blablabla</p>
                                                    >
                                                    > 2) By adding tags/attributes to an XML schema for the document
                                                    > format in question.

                                                    And 3) by adding a set of "dislocated" rules in a separate standalone file, or somewhere in a document instance. This for example to
                                                    work with XML formats that do not use schemas (but DTD).

                                                    Cheers,
                                                    -yves
                                                  • JC Helary
                                                    ... 1) will have to be supported eventually if/when the proposal becomes a standard. ... So we could establish definition lists based on ITS to ease the
                                                    Message 25 of 28 , Jan 2, 2006
                                                    • 0 Attachment
                                                      > 1) By adding the attribute its:translate to an element that contains
                                                      > translatable content, for example <p its:translate="yes">blablabla</p>
                                                      >
                                                      > 2) By adding tags/attributes to an XML schema for the document
                                                      > format in
                                                      > question.
                                                      >
                                                      > I don't think 1) will be of much concern, but 2) can be quite
                                                      > interesting.

                                                      1) will have to be supported eventually if/when the proposal becomes
                                                      a standard.

                                                      >> So if my understanding is correct, we still need to get an idea of
                                                      >> where can the translatable strings be found in the xml structure
                                                      >>
                                                      > That's what 2) does. It can specify, for example, that the contents
                                                      > of a
                                                      > <title> in a <head> are translatable.

                                                      So we could establish "definition lists" based on ITS to ease the
                                                      parsing. ?
                                                      Which means that the tags list that we are trying to establish on an
                                                      arbitrary basis for parsing source files could be established either
                                                      by ITS (xhtml/docbook/od, yet "todo") or by "us" ?

                                                      Besides for the fact that the description job is delegated to ITS's
                                                      "official implementation" in what way would that be interesting ?

                                                      JC

                                                      (hoping to read your answer in the morning!)
                                                    • Henry Pijffers
                                                      ... We can always write our own internal schema for any format we wish to support. But yes, 3) is another useful option. Henry
                                                      Message 26 of 28 , Jan 2, 2006
                                                      • 0 Attachment
                                                        Yves Savourel wrote:
                                                        >
                                                        > And 3) by adding a set of "dislocated" rules in a separate standalone file, or somewhere in a document instance. This for example to
                                                        > work with XML formats that do not use schemas (but DTD).
                                                        >
                                                        We can always write our own internal schema for any format we wish to
                                                        support. But yes, 3) is another useful option.

                                                        Henry
                                                      • Henry Pijffers
                                                        ... The fact that something is a standard, does not mean it should be supported. It should be supported when the standard gets acceptance and is used enough.
                                                        Message 27 of 28 , Jan 2, 2006
                                                        • 0 Attachment
                                                          JC Helary wrote:
                                                          >
                                                          >> 1) By adding the attribute its:translate to an element that contains
                                                          >> translatable content, for example <p its:translate="yes">blablabla</p>
                                                          >>
                                                          >> 2) By adding tags/attributes to an XML schema for the document
                                                          >> format in
                                                          >> question.
                                                          >>
                                                          >> I don't think 1) will be of much concern, but 2) can be quite
                                                          >> interesting.
                                                          >
                                                          > 1) will have to be supported eventually if/when the proposal becomes
                                                          > a standard.
                                                          >
                                                          The fact that something is a standard, does not mean it should be
                                                          supported. It should be supported when the standard gets acceptance and
                                                          is used enough.

                                                          >>> So if my understanding is correct, we still need to get an idea of
                                                          >>> where can the translatable strings be found in the xml structure
                                                          >>>
                                                          >> That's what 2) does. It can specify, for example, that the contents
                                                          >> of a <title> in a <head> are translatable.
                                                          >
                                                          > So we could establish "definition lists" based on ITS to ease the
                                                          > parsing. ?
                                                          >
                                                          Yes. For every type of XML document we want to support, we could write
                                                          an ITS document, which specifies the translatable parts in each document
                                                          type. We can then feed a document and the appropriate ITS document to a
                                                          generic XML filter that passes the translatable bits to OmegaT.

                                                          > Which means that the tags list that we are trying to establish on an
                                                          > arbitrary basis for parsing source files could be established either
                                                          > by ITS (xhtml/docbook/od, yet "todo") or by "us" ?
                                                          >
                                                          Yes. When ITS is finished, it'll have specifications for XHTML, DocBook,
                                                          and OpenDocument, which we can employ immediately. For other document
                                                          types (MSO12, Abiword, Pages, etc.) we can write the specs ourselves.

                                                          > Besides for the fact that the description job is delegated to ITS's
                                                          > "official implementation" in what way would that be interesting ?
                                                          >
                                                          We don't have to invent stuff that has already been invented. A lot of
                                                          people have given thought to this problem, why would we (well, one of us
                                                          more likely) do it all over again? The person that would get this task
                                                          would most probably produce something much less useful than ITS.

                                                          Henry
                                                        • Yves Savourel
                                                          ... Quite right Henry. But it could be a case of the egg and the hent infinite loop: If the tools don t support it why the developers/authors of XML
                                                          Message 28 of 28 , Jan 2, 2006
                                                          • 0 Attachment
                                                            >> 1) will have to be supported eventually if/when the proposal becomes a
                                                            >> standard.
                                                            >>
                                                            > The fact that something is a standard, does not mean it should be
                                                            > supported. It should be supported when the standard gets acceptance
                                                            > and is used enough.

                                                            Quite right Henry. But it could be a case of "the egg and the hent" infinite loop: If the tools don't support it why the
                                                            developers/authors of XML documents would bother support it either? One has to start the chain reaction. OmegaT could be one of the
                                                            detonators :)


                                                            >> So we could establish "definition lists" based on ITS to ease the
                                                            >> parsing. ?
                                                            >
                                                            > Yes. For every type of XML document we want to support, we could
                                                            > write an ITS document, which specifies the translatable parts in each
                                                            > document type. We can then feed a document and the appropriate ITS
                                                            > document to a generic XML filter that passes the translatable bits
                                                            > to OmegaT.

                                                            And we could use any ITS document that would be done by others also supporting ITS.
                                                            The idea is to have the developers/authors of the various XML formats to define their ITS document as they create their format.
                                                            After all they are the ones who know exactly what each element are.

                                                            Kenavo,
                                                            -yves
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.