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: Re: [xliff] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"

That's an interesting approach, and shows how something like this could be made to work in XLIFF. Rodolfo provided another way to me earlier in a conversation that is even more XLIFF-like in its output (it involved “exploding” the selectors to create a full set of all the possibilities that could be easily translated in XLIFF) and would put the difficulty of dealing with the strange variable notation into the filter and produce clean and clear XLIFF. So there are ways to deal with it and which would be better probably depends on a lot of factors.

But this was all an example to get at a principle that I think is now resolved.



On Nov 17, 2011, at 12:19 , Yves Savourel wrote:

>> I think we're all in agreement then. Your mention of using 
>> <ph> is what I had in mind by saying that this made-
>> up format would be treated just like IDML, Word, etc.
> Actually I meant to say that *instead* of using the elements in your example, they could probably have a different set of elements/attributes that would work in the XLIFF core. So there would be no need for additional filtering, etc.
> The following is such an example. Here it make probably no sense because I don't know what those elements means, but the idea is that you can likely adapt your data model to XLIFF.
> <unit id="item1">
> <source><ph id='1' gx:ref='A'>$1</ph> kill<ph id='2' gx:ref='B'>{past}</ph> <ph id='3' gx:ref='C'>$2</ph> with a sword</source>
> ...
> <gx:varTextParams>
>  <gx:textVariableSet var_id="A" number="sing" case="nominative">
>   <gx:selector selectorID="1" gender="masc"><gx:name/></gx:selector>
>   <gx:selector selectorID="2" gender="fem"><gx:name/></gx:selector>
>  </gx:textVariableSet>
>  ...etc.
> </gx:varTextParams>
> </unit>
> And that would be better than go to some proprietary format first, and then go to XLIFF from that proprietary format. The fewer intermediary steps the better.
> By the way we do have a feature in the "proposed" category that deals with representation of plural. That may be related to your example. (http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries)
> Cheers,
> -ys
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org

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