OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  ULI

    Posted 05-03-2011 12:02
    FYI: A new TC at the Unicode Consortium http://unicode-inc.blogspot.com/2011/04/unicode-consortium-announces.html Interesting. So, what happens when something published by the ULI TC and something published by the XLIFF TC are contradictory? Cheers, -ys


  • 2.  RE: [xliff] ULI

    Posted 05-03-2011 14:25
    I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


  • 3.  RE: [xliff] ULI

    Posted 05-03-2011 16:16
    As mentioned, I'd like to call an off-line meeting. Please write me if you are interested. Agenda: - I have some idea of the initial focus area: SRX and TMX related. Specifically,         1. TR29 specifying the definition and types of textual segmentation rules that applies across the entire life cycle of content, not just during translation phase.         2. SRX being the interchange standards for #1.         3. CLDR to publish language specific segmentation behavior. Following the core/module concept, the specialty module would not be expected to be 100% interoperable. However, core should.         4. Sort out whether there is a need for memory specific standards outside XLIFF. I have a list of concerns and issues to share. See below. - Any of the above does not belong in Unicode? I need your input on what to stay out of or mind my own business and WHY? What type of interaction point would be needed between the two? I plan to call this meeting soon before I kick off the ULI activity on the Unicode side. Please write me by noon EDT Wed May 4th with a few availability options and I will send invitation shortly after. I will not be able to accommodate all the requirements, my apologies in advance. Best regards, Helena Shih Chapman Globalization Technologies and Architecture +1-720-396-6323 or T/L 938-6323 Waltham, Massachusetts From:         "Lucia.Morado" <Lucia.Morado@ul.ie> To:         "Yves Savourel" <ysavourel@translate.com>, <xliff@lists.oasis-open.org> Date:         05/03/2011 10:30 AM Subject:         RE: [xliff] ULI I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


  • 4.  RE: [xliff] ULI

    Posted 05-03-2011 16:28
    Forgot to mention IBM concerns: - Integration of memory specification in under XLIFF or separately thru Unicode ULI TC. Unless we can do the following, We are not entirely convinced TMX should not live on its own:         * <trans_unit> be limited to one entry per segment and not more         * restructure the <source> and <target> against the TMX <tuv xml:lang="xx"> tags. However, I do not see a need of specifying more than one language pair at a time. That is something never used in practice in TMX         * fold the <note> and <prop> tags together         * TMX needs <note> on <tuv> level because the translator may have added comments are to why the text was translated this way From:         Helena S Chapman/San Jose/IBM@IBMUS To:         "Lucia.Morado" <Lucia.Morado@ul.ie> Cc:         xliff@lists.oasis-open.org, "Yves Savourel" <ysavourel@translate.com> Date:         05/03/2011 12:18 PM Subject:         RE: [xliff] ULI As mentioned, I'd like to call an off-line meeting. Please write me if you are interested. Agenda: - I have some idea of the initial focus area: SRX and TMX related. Specifically,        1. TR29 specifying the definition and types of textual segmentation rules that applies across the entire life cycle of content, not just during translation phase.        2. SRX being the interchange standards for #1.        3. CLDR to publish language specific segmentation behavior. Following the core/module concept, the specialty module would not be expected to be 100% interoperable. However, core should.        4. Sort out whether there is a need for memory specific standards outside XLIFF. I have a list of concerns and issues to share. See below. - Any of the above does not belong in Unicode? I need your input on what to stay out of or mind my own business and WHY? What type of interaction point would be needed between the two? I plan to call this meeting soon before I kick off the ULI activity on the Unicode side. Please write me by noon EDT Wed May 4th with a few availability options and I will send invitation shortly after. I will not be able to accommodate all the requirements, my apologies in advance. Best regards, Helena Shih Chapman Globalization Technologies and Architecture +1-720-396-6323 or T/L 938-6323 Waltham, Massachusetts From:         "Lucia.Morado" <Lucia.Morado@ul.ie> To:         "Yves Savourel" <ysavourel@translate.com>, <xliff@lists.oasis-open.org> Date:         05/03/2011 10:30 AM Subject:         RE: [xliff] ULI I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


  • 5.  RE: [xliff] ULI

    Posted 05-03-2011 16:55
    Hi Helena,   In the few minutes I requested for after the meeting I proposed an idea: include in XLIFF 2.0 a set of optional modules for holding TM data (something like TMX), glossary data, segmentation rules (something along the lines of SRX).   A translation job requires multiple files, source documents, XLIFF (or equivalent), TMX files and glossaries. What I´m proposing would reduce the number of files involved, by including some of the usual exchange files into an XLIFF 2.0 document.   If we define our own formats for TM, glossary and segmentation rules, we would be independent from LISA, ETSI, Unicode and others.   Those containers would be absolutely optional but could help in interoperability if developers have to deal with just on technical committee defining exchange rules.   Best regards, Rodolfo -- Rodolfo M. Raya   <rmraya@maxprograms.com> Maxprograms      http://www.maxprograms.com   From: Helena S Chapman [mailto:hchapman@us.ibm.com] Sent: Tuesday, May 03, 2011 1:27 PM To: Helena S Chapman Cc: Lucia.Morado; xliff@lists.oasis-open.org; Yves Savourel Subject: RE: [xliff] ULI   Forgot to mention IBM concerns: - Integration of memory specification in under XLIFF or separately thru Unicode ULI TC. Unless we can do the following, We are not entirely convinced TMX should not live on its own:         * <trans_unit> be limited to one entry per segment and not more         * restructure the <source> and <target> against the TMX <tuv xml:lang="xx"> tags. However, I do not see a need of specifying more than one language pair at a time. That is something never used in practice in TMX         * fold the <note> and <prop> tags together         * TMX needs <note> on <tuv> level because the translator may have added comments are to why the text was translated this way From:         Helena S Chapman/San Jose/IBM@IBMUS To:         "Lucia.Morado" < Lucia.Morado@ul.ie > Cc:         xliff@lists.oasis-open.org , "Yves Savourel" < ysavourel@translate.com > Date:         05/03/2011 12:18 PM Subject:         RE: [xliff] ULI As mentioned, I'd like to call an off-line meeting. Please write me if you are interested. Agenda: - I have some idea of the initial focus area: SRX and TMX related. Specifically,        1. TR29 specifying the definition and types of textual segmentation rules that applies across the entire life cycle of content, not just during translation phase.        2. SRX being the interchange standards for #1.        3. CLDR to publish language specific segmentation behavior. Following the core/module concept, the specialty module would not be expected to be 100% interoperable. However, core should.        4. Sort out whether there is a need for memory specific standards outside XLIFF. I have a list of concerns and issues to share. See below. - Any of the above does not belong in Unicode? I need your input on what to stay out of or mind my own business and WHY? What type of interaction point would be needed between the two? I plan to call this meeting soon before I kick off the ULI activity on the Unicode side. Please write me by noon EDT Wed May 4th with a few availability options and I will send invitation shortly after. I will not be able to accommodate all the requirements, my apologies in advance. Best regards, Helena Shih Chapman Globalization Technologies and Architecture +1-720-396-6323 or T/L 938-6323 Waltham, Massachusetts From:         "Lucia.Morado" < Lucia.Morado@ul.ie > To:         "Yves Savourel" < ysavourel@translate.com >, < xliff@lists.oasis-open.org > Date:         05/03/2011 10:30 AM Subject:         RE: [xliff] ULI I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


  • 6.  XLIFF and TM, Glossary, Segmenation Rules - Was: RE: [xliff] ULI

    Posted 05-10-2011 06:13
    Hi Rodolfo,   I have some concerns related to your comment/proposal   RR> If we define our own formats for TM, glossary and segmentation rules, we would be independent from LISA, ETSI, Unicode and others.   Here are some of them:   1.        The charter of the XLIFF TC delineates the TC’s scope. We would have to check that the charter covers the proposal. 2.        The bandwidth and the expertise of the TC members may not allow the comprehensive coverage/scope that you propose. 3.        “define our own formats” may lead to a situation in which requirements are not captured properly, and synergies and economies of scale are not possible.   Best regards, Christian   From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] Sent: Dienstag, 3. Mai 2011 18:54 To: xliff@lists.oasis-open.org Subject: RE: [xliff] ULI   Hi Helena,   In the few minutes I requested for after the meeting I proposed an idea: include in XLIFF 2.0 a set of optional modules for holding TM data (something like TMX), glossary data, segmentation rules (something along the lines of SRX).   A translation job requires multiple files, source documents, XLIFF (or equivalent), TMX files and glossaries. What I´m proposing would reduce the number of files involved, by including some of the usual exchange files into an XLIFF 2.0 document.   If we define our own formats for TM, glossary and segmentation rules, we would be independent from LISA, ETSI, Unicode and others.   Those containers would be absolutely optional but could help in interoperability if developers have to deal with just on technical committee defining exchange rules.   Best regards, Rodolfo -- Rodolfo M. Raya   <rmraya@maxprograms.com> Maxprograms      http://www.maxprograms.com   From: Helena S Chapman [mailto:hchapman@us.ibm.com] Sent: Tuesday, May 03, 2011 1:27 PM To: Helena S Chapman Cc: Lucia.Morado; xliff@lists.oasis-open.org; Yves Savourel Subject: RE: [xliff] ULI   Forgot to mention IBM concerns: - Integration of memory specification in under XLIFF or separately thru Unicode ULI TC. Unless we can do the following, We are not entirely convinced TMX should not live on its own:         * <trans_unit> be limited to one entry per segment and not more         * restructure the <source> and <target> against the TMX <tuv xml:lang="xx"> tags. However, I do not see a need of specifying more than one language pair at a time. That is something never used in practice in TMX         * fold the <note> and <prop> tags together         * TMX needs <note> on <tuv> level because the translator may have added comments are to why the text was translated this way From:         Helena S Chapman/San Jose/IBM@IBMUS To:         "Lucia.Morado" < Lucia.Morado@ul.ie > Cc:         xliff@lists.oasis-open.org , "Yves Savourel" < ysavourel@translate.com > Date:         05/03/2011 12:18 PM Subject:         RE: [xliff] ULI As mentioned, I'd like to call an off-line meeting. Please write me if you are interested. Agenda: - I have some idea of the initial focus area: SRX and TMX related. Specifically,        1. TR29 specifying the definition and types of textual segmentation rules that applies across the entire life cycle of content, not just during translation phase.        2. SRX being the interchange standards for #1.        3. CLDR to publish language specific segmentation behavior. Following the core/module concept, the specialty module would not be expected to be 100% interoperable. However, core should.        4. Sort out whether there is a need for memory specific standards outside XLIFF. I have a list of concerns and issues to share. See below. - Any of the above does not belong in Unicode? I need your input on what to stay out of or mind my own business and WHY? What type of interaction point would be needed between the two? I plan to call this meeting soon before I kick off the ULI activity on the Unicode side. Please write me by noon EDT Wed May 4th with a few availability options and I will send invitation shortly after. I will not be able to accommodate all the requirements, my apologies in advance. Best regards, Helena Shih Chapman Globalization Technologies and Architecture +1-720-396-6323 or T/L 938-6323 Waltham, Massachusetts From:         "Lucia.Morado" < Lucia.Morado@ul.ie > To:         "Yves Savourel" < ysavourel@translate.com >, < xliff@lists.oasis-open.org > Date:         05/03/2011 10:30 AM Subject:         RE: [xliff] ULI I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


  • 7.  RE: XLIFF and TM, Glossary, Segmenation Rules - Was: RE: [xliff] ULI

    Posted 05-10-2011 09:28
    HI Christian:   Some comments to your comments:   1)       The charter is outdated. It does not cover XLIFF 2.0. We have to change it anyway. 2)       We have people in the TC with enough experience about TM and glossary data management. In any case, I already provided an actual Schema that contains the proposed changes; only TC review is remaining. 3)       The changes I already proposed are based on TMX and GlossML, two formats that have been analyzed and discussed quite enough.   In essence, the main work is done and the TC has the power to accept or reject. If the idea is accepted , the work can be refined and improved.   Regards, Rodolfo -- Rodolfo M. Raya   <rmraya@maxprograms.com> Maxprograms      http://www.maxprograms.com   From: Lieske, Christian [mailto:christian.lieske@sap.com] Sent: Tuesday, May 10, 2011 3:13 AM To: Rodolfo M. Raya; xliff@lists.oasis-open.org Subject: XLIFF and TM, Glossary, Segmenation Rules - Was: RE: [xliff] ULI   Hi Rodolfo,   I have some concerns related to your comment/proposal   RR> If we define our own formats for TM, glossary and segmentation rules, we would be independent from LISA, ETSI, Unicode and others.   Here are some of them:   1.        The charter of the XLIFF TC delineates the TC’s scope. We would have to check that the charter covers the proposal. 2.        The bandwidth and the expertise of the TC members may not allow the comprehensive coverage/scope that you propose. 3.        “define our own formats” may lead to a situation in which requirements are not captured properly, and synergies and economies of scale are not possible.   Best regards, Christian   From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] Sent: Dienstag, 3. Mai 2011 18:54 To: xliff@lists.oasis-open.org Subject: RE: [xliff] ULI   Hi Helena,   In the few minutes I requested for after the meeting I proposed an idea: include in XLIFF 2.0 a set of optional modules for holding TM data (something like TMX), glossary data, segmentation rules (something along the lines of SRX).   A translation job requires multiple files, source documents, XLIFF (or equivalent), TMX files and glossaries. What I´m proposing would reduce the number of files involved, by including some of the usual exchange files into an XLIFF 2.0 document.   If we define our own formats for TM, glossary and segmentation rules, we would be independent from LISA, ETSI, Unicode and others.   Those containers would be absolutely optional but could help in interoperability if developers have to deal with just on technical committee defining exchange rules.   Best regards, Rodolfo -- Rodolfo M. Raya   < rmraya@maxprograms.com > Maxprograms      http://www.maxprograms.com   From: Helena S Chapman [mailto:hchapman@us.ibm.com] Sent: Tuesday, May 03, 2011 1:27 PM To: Helena S Chapman Cc: Lucia.Morado; xliff@lists.oasis-open.org; Yves Savourel Subject: RE: [xliff] ULI   Forgot to mention IBM concerns: - Integration of memory specification in under XLIFF or separately thru Unicode ULI TC. Unless we can do the following, We are not entirely convinced TMX should not live on its own:         * <trans_unit> be limited to one entry per segment and not more         * restructure the <source> and <target> against the TMX <tuv xml:lang="xx"> tags. However, I do not see a need of specifying more than one language pair at a time. That is something never used in practice in TMX         * fold the <note> and <prop> tags together         * TMX needs <note> on <tuv> level because the translator may have added comments are to why the text was translated this way From:         Helena S Chapman/San Jose/IBM@IBMUS To:         "Lucia.Morado" < Lucia.Morado@ul.ie > Cc:         xliff@lists.oasis-open.org , "Yves Savourel" < ysavourel@translate.com > Date:         05/03/2011 12:18 PM Subject:         RE: [xliff] ULI As mentioned, I'd like to call an off-line meeting. Please write me if you are interested. Agenda: - I have some idea of the initial focus area: SRX and TMX related. Specifically,        1. TR29 specifying the definition and types of textual segmentation rules that applies across the entire life cycle of content, not just during translation phase.        2. SRX being the interchange standards for #1.        3. CLDR to publish language specific segmentation behavior. Following the core/module concept, the specialty module would not be expected to be 100% interoperable. However, core should.        4. Sort out whether there is a need for memory specific standards outside XLIFF. I have a list of concerns and issues to share. See below. - Any of the above does not belong in Unicode? I need your input on what to stay out of or mind my own business and WHY? What type of interaction point would be needed between the two? I plan to call this meeting soon before I kick off the ULI activity on the Unicode side. Please write me by noon EDT Wed May 4th with a few availability options and I will send invitation shortly after. I will not be able to accommodate all the requirements, my apologies in advance. Best regards, Helena Shih Chapman Globalization Technologies and Architecture +1-720-396-6323 or T/L 938-6323 Waltham, Massachusetts From:         "Lucia.Morado" < Lucia.Morado@ul.ie > To:         "Yves Savourel" < ysavourel@translate.com >, < xliff@lists.oasis-open.org > Date:         05/03/2011 10:30 AM Subject:         RE: [xliff] ULI I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


  • 8.  Re: [xliff] XLIFF and TM, Glossary, Segmenation Rules - Was: RE: [xliff] ULI

    Posted 05-10-2011 11:11
    I also have concern with the same statement.
    If we want to be completely independent of Unicode, let's consider redefining
    UTF-8, 16, 32 as well since that is how content is commonly encoded when
    exchanged. On top of that, we should also redefine BCP 47 in case we ever
    needed to tell each other which locale and scripts we are exchanging the
    content with.

    Bottom line, interdependency to reputable
    standard organization is a good thing. Having to be "contingent"
    upon not-so-active standard organization is a bad thing. A kitchen-and-sink/cover-it-all
    standard and implementation has not proven to work well in my programming
    experiences. I quite frankly disagree with the approach. Referencing another
    standard within the context is a better method.

    Best regards,

    Helena Shih Chapman
    Globalization Technologies and Architecture
    +1-720-396-6323 or T/L 938-6323
    Waltham, Massachusetts




    From:      
      "Lieske, Christian"
    <christian.lieske@sap.com>
    To:      
      "Rodolfo M. Raya"
    <rmraya@maxprograms.com>, "xliff@lists.oasis-open.org"
    <xliff@lists.oasis-open.org>
    Date:      
      05/10/2011 02:13 AM
    Subject:    
        [xliff] XLIFF
    and TM, Glossary, Segmenation Rules - Was: RE: [xliff] ULI




    Hi Rodolfo,
     
    I have some concerns related
    to your comment/proposal
     
    RR> If we define our own
    formats for TM, glossary and segmentation rules, we would be independent
    from LISA, ETSI, Unicode and others.
     
    Here are some of them:
     
    1.       The
    charter of the XLIFF TC delineates the TC ??s scope. We would have to check
    that the charter covers the proposal.
    2.       The
    bandwidth and the expertise of the TC members may not allow the comprehensive
    coverage/scope that you propose.
    3.       ??define
    our own formats ? may lead to a situation in which requirements are not
    captured properly, and synergies and economies of scale are not possible.
     
    Best regards,
    Christian
     
    From: Rodolfo M. Raya [ mailto:rmraya@maxprograms.com ]

    Sent: Dienstag, 3. Mai 2011 18:54
    To: xliff@lists.oasis-open.org
    Subject: RE: [xliff] ULI
     
    Hi Helena,
     
    In the few minutes I requested
    for after the meeting I proposed an idea: include in XLIFF 2.0 a set of
    optional modules for holding TM data (something like TMX), glossary data,
    segmentation rules (something along the lines of SRX).
     
    A translation job requires
    multiple files, source documents, XLIFF (or equivalent), TMX files and
    glossaries. What I ´m proposing would reduce the number of files involved,
    by including some of the usual exchange files into an XLIFF 2.0 document.

     
    If we define our own formats
    for TM, glossary and segmentation rules, we would be independent from LISA,
    ETSI, Unicode and others.
     
    Those containers would be
    absolutely optional but could help in interoperability if developers have
    to deal with just on technical committee defining exchange rules.
     
    Best regards,
    Rodolfo
    --
    Rodolfo M. Raya  
    <rmraya@maxprograms.com>
    Maxprograms    
      http://www.maxprograms.com
     
    From: Helena S Chapman [ mailto:hchapman@us.ibm.com ]

    Sent: Tuesday, May 03, 2011 1:27 PM
    To: Helena S Chapman
    Cc: Lucia.Morado; xliff@lists.oasis-open.org; Yves Savourel
    Subject: RE: [xliff] ULI
     
    Forgot to mention IBM concerns:

    - Integration of memory specification in under XLIFF or separately thru
    Unicode ULI TC. Unless we can do the following, We are not entirely convinced
    TMX should not live on its own:
           * <trans_unit> be limited to one entry
    per segment and not more
           * restructure the <source> and <target>
    against the TMX <tuv xml:lang="xx"> tags. However, I do
    not see a need of specifying more than one language pair at a time. That
    is something never used in practice in TMX

           * fold the <note> and <prop> tags
    together
           * TMX needs <note> on <tuv> level
    because the translator may have added comments are to why the text was
    translated this way





    From:         Helena
    S Chapman/San Jose/IBM@IBMUS

    To:         "Lucia.Morado"
    < Lucia.Morado@ul.ie >

    Cc:         xliff@lists.oasis-open.org ,
    "Yves Savourel" < ysavourel@translate.com >

    Date:         05/03/2011
    12:18 PM
    Subject:         RE:
    [xliff] ULI






    As mentioned, I'd like to call an off-line meeting. Please write me if
    you are interested. Agenda:

    - I have some idea of the initial focus area: SRX and TMX related. Specifically,

          1. TR29 specifying the definition and types of textual
    segmentation rules that applies across the entire life cycle of content,
    not just during translation phase.

          2. SRX being the interchange standards for #1.

          3. CLDR to publish language specific segmentation
    behavior. Following the core/module concept, the specialty module would
    not be expected to be 100% interoperable. However, core should.

          4. Sort out whether there is a need for memory specific
    standards outside XLIFF. I have a list of concerns and issues to share.
    See below.
    - Any of the above does not belong in Unicode? I need your input on what
    to stay out of or mind my own business and WHY? What type of interaction
    point would be needed between the two?

    I plan to call this meeting soon before I kick off the ULI activity on
    the Unicode side. Please write me by noon EDT Wed May 4th with a few availability
    options and I will send invitation shortly after. I will not be able to
    accommodate all the requirements, my apologies in advance.


    Best regards,

    Helena Shih Chapman
    Globalization Technologies and Architecture
    +1-720-396-6323 or T/L 938-6323
    Waltham, Massachusetts




    From:         "Lucia.Morado"
    < Lucia.Morado@ul.ie >

    To:         "Yves
    Savourel" < ysavourel@translate.com >,
    < xliff@lists.oasis-open.org >

    Date:         05/03/2011
    10:30 AM
    Subject:         RE:
    [xliff] ULI






    I see Helena as the current TC officer, she might clarify this in
    today's meeting. http://unicode.org/uli/

    Lucia

    >
    Original Message


  • 9.  RE: [xliff] ULI

    Posted 05-03-2011 17:21
    Hi Helena, > ... However, I do not see a need of specifying > more than one language pair at a time. That is something never > used in practice in TMX. About XLIFF not needing more than one pair at a time: +1 But as far as having multi-lingual entries in TMX files, this is done quite often in practice from my experience. > * TMX needs <note> on <tuv> level because the > translator may have added comments are to why > the text was translated this way TMX has already a <note> for the <tuv> level. Cheers, -yves


  • 10.  Re: [xliff] ULI

    Posted 05-03-2011 21:58
    Hi Helena, I am interested.. I will try to accomodate my schedule, I just absolutely cannot do it on 12th and 13th of May.. My feedback to the announcement and its focus is that it should not make direct reference to LISA OSCAR standards becuase of their fishy legal status.. I like the idea of absolutely interoperable segmentation core and the language specific additions.. The exchange format of course will be like SRX and it will most probably be inspired by SRX, it can even reference SRX if it will be at last published by ISO TC 37 or even ETSI. But I strongly believe that ULI should put forward its own segmentation exchange standard succesor that will be fully and safely owned by Unicode.. Regarding the TM exchange, I strongly believe this is an XLIFF issue. TM leverage in XLIFF should be realized 1) through an <alt-trans> successor that can possibly be in core.. 2) TC should describe best practice how to use translated XLIFF body itself for further leverage 3) there should be an option for a TMX like container for including potentially useful legacy pairs without knowing if they pertain to particular segments, this could be called concordnace exchange container.. I believe that TM leverage is not at all in Unicode's domain Finally there is terminology, and although TBX is a published ISO standard, the likelihood that it will be further developed within TC 37 or elsewhere is quite low. TBX despite being very heavy, so heavy that it had to produce one lightweight and one even lighter version, it has serious deficiencies, like not allowing hierarchical relationships, poor handling of morphology etc. TBX successor is a big beast and I can see parts of it addressed by Unicode, i.e. the morphology bit, but for instance the ontology modelling should go to W3C.. XLIFF should only reference various standard glossary formats including TBX falvors and successors without attempting own standardization in this area.. We should be able to start adressing this with LT-Web, which gets the funding, actually we go negotiate for the money on 12th and 13th.. The other bits should get serious thrust if we get the LT-Infra funding in early 2012.. Rgds dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone:  +353-61- 202781 mobile: +420-777-218122 mailto: david.filip@ul.ie On Tue, May 3, 2011 at 17:14, Helena S Chapman < hchapman@us.ibm.com > wrote: As mentioned, I'd like to call an off-line meeting. Please write me if you are interested. Agenda: - I have some idea of the initial focus area: SRX and TMX related. Specifically,         1. TR29 specifying the definition and types of textual segmentation rules that applies across the entire life cycle of content, not just during translation phase.         2. SRX being the interchange standards for #1.         3. CLDR to publish language specific segmentation behavior. Following the core/module concept, the specialty module would not be expected to be 100% interoperable. However, core should.         4. Sort out whether there is a need for memory specific standards outside XLIFF. I have a list of concerns and issues to share. See below. - Any of the above does not belong in Unicode? I need your input on what to stay out of or mind my own business and WHY? What type of interaction point would be needed between the two? I plan to call this meeting soon before I kick off the ULI activity on the Unicode side. Please write me by noon EDT Wed May 4th with a few availability options and I will send invitation shortly after. I will not be able to accommodate all the requirements, my apologies in advance. Best regards, Helena Shih Chapman Globalization Technologies and Architecture +1-720-396-6323 or T/L 938-6323 Waltham, Massachusetts From:         "Lucia.Morado" < Lucia.Morado@ul.ie > To:         "Yves Savourel" < ysavourel@translate.com >, < xliff@lists.oasis-open.org > Date:         05/03/2011 10:30 AM Subject:         RE: [xliff] ULI I see Helena as the current TC officer, she might clarify this in today's meeting. http://unicode.org/uli/ Lucia >
    Original Message


Related Content