OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 Im 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-----
> From: Yves Savourel [
mailto:ysavourel@translate.com]
> Sent: 03 May 2011 13:01
> To: xliff@lists.oasis-open.org
> Subject: [xliff] ULI
>
> FYI:
>
> A new TC at the Unicode Consortium
>

http://unicode-inc.blogspot.com/2011/04/unicode-consortium-announces.htm
l
>
> Interesting.
> So, what happens when something published by the ULI TC and something
> published by the XLIFF TC are contradictory?
>
> Cheers,
> -ys
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]