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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-seg message

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


Subject: Meeting Minutes


Here are the minutes of todays' meeting.
Cheers,
-yves

Segmentation Subcommittee Meeting
September-28-2004

1- Roll Call:
Magnus, Andrzej, Tony, Gerard, Yves, Eiju, Christian


2- Approval of Minutes from Last Meeting:
	Yves moved to accept the minutes, Magnus seconded. Minutes were approved.


3- Open Action Items from previous meetings:

	* Magnus checked for test files with his QA dept. But they have client information so we can't use them.

	* Summary of differenet options: done during lats meeting.



4. Work in Progress 

Magnus recapitulated teh different options we seem to have reached.

Andrzej noted that it was important to keep the method of restructuring the document (during a 'pipeline' process) in our set of possibilities because it works in some cases, even if we need possibly other solution for other cases.

Magnus underlined that the main issue with using markers inside the <source> and <target> was to solve the problem of segmentation coming at the middle of a <g> element, or equivalent.
Another issue is how to keep the merkers in synch between source and target (and in <alt-trans>).

Magnus ask for a round of the table to get everybody's input.

Tony favor using existing elements (e.g. <group>, <trans-unit>) with maybe some custom attributes in addition to help the reconstruction of the file. He noted that this was possible a better solution from the resource-type formats viewpoint, but maybe inline markers would be better for documentation-type data.

Gerard explained that most of his segmentation would probably occur in the case of 'bloaded string' (string that are really paragraphs). Maybe there including inline markers would be easier since the integrity of the original string could be preserved.
Maybe we needed two solutions for two scenarios (UI or content)

Magnus noted that 'paragraphs' from the document-type content are in a large extend similar to the strings. And need to be preserved as a unit to be merged back.

Andrzej said that the differences between the two types of data were not that great and the requirements were often the same, as far as segmentation.
The nature of XLIFF is to use source and target tightly coupled and it is never easy to break that coupling without creating some problems. Andrzej also noted that it was important for the translator to be able to override the segmentation.

Yves concured, adding that maybe we needed a way to indicate when a document was 'pre-segmented' (TUs restructured to match the segmentation) so tools would not try to re-segment it, and they could apply whatever inline solution on the other kind of TUs.

Christian noted that it seemed important to have such notation (segment yes/no) so tools can behave accordingly.

Gerard said that it boils down to two types of segmentation: inside a TU, or across TUs

Christian said that we may want to solve the simple case first.

Magnus was torn between the two approcahes: markers seems easier to work with, but restructuration seems better for keeping macthed source and target. He noted that one possibility to solve the problem of segmenting inside elements would be to use placeholders. There are two types of boudaries: linguistic and structural (driven by the file format).

Andrzej proposed to put in writting the three current proposal we have:
- an attribute for indicating TU merging/not merging
- an attribute for no-equiv
- the solution for 'pipline processes' of restructuring the files (it works with the current XLIFF tag set)

Christian agreed that having this on paper would help.

==> This is an action itemn for Andrzej.



5. Any Other Business

None.


Next meeting is the second Tuesday of October (Oct-12)


Action Items:

	* Andrzej: To put in writing the three proposal for which we have apparently a general consensus.






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