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] 2.0 Validations Module Proposal


> [ryanki] Good question. Maybe an attribute should be added 
> to allow a user to define the regex language to use?

That one step toward better interoperability and at the same time, possibly toward less:
Tools can identify what is the regex syntax, but now they have to implement more than one syntax.
I don't have an answer, just thinking aloud.


> [ryanki] Since maxLength is just another type of validation, 
> we would advocate replacing it with the more general 
> <validations> module. 

That's a good argument.
Based on the module proposal Fredrik just posted it seems a complex one. maybe maxLength is just one of the many profiles?
just thinking aloud here too.


> [ryanki] If you have the following source “Hello Microsoft” 
> the tendency would be to use <mrk> to annotate it, or similarly, if I 
> have “Hello %s”, the tendency might be to use <ph> to encode it. 
> However, both cases introduce markup into my source that I may 
> have to normalize during recycling to get a 100% match. So having 
> a noLoc rule is a way to provide a “cleaner, no post-processing needed” 
> source for recycling.  

But now you have also a "don't translate" information decoupled from the segment that tools have to carry along with it. In many use cases having the inline markup is simpler and easier to work with (e.g. send the text to MT, etc.)
Just thinking aloud here too.

cheers,
-yves




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