[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs
Hi Bryan, The focus should not be in just images, the "fs" attribute needs to work in any circumstance. The workaround to store image paths is too specific. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com > -----Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf > Of Schnabel, Bryan S > Sent: Monday, October 08, 2012 4:39 PM > To: Yves Savourel; xliff@lists.oasis-open.org > Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs > > Hi Yves, > > Ok. Now I’ve got it. (1) Make fs interoperable; (2) Add an fs mechanism to > store the path of images to render. And presumable doing (2) helps achieve > (1). > > Maybe we are in violent agreement after all. > > I’m in favor of (1) – and I’m not aware of how anything I said earlier in the > thread is counter to that, including my observation that some XLIFF will be > good candidates for fs, and some XLIFF will not (interoperable - ly, across the > board for all). Example, I cannot imagine my firmware XLIFF files lending > themselves to a just-in-time browser view facilitated by fs – nothing to do > with interoperability. > > If you are saying that my attempts to render images via fs, based on non-fs- > contained information, located elsewhere in an XLIFF file contradicts > interoperability – I say okay – let’s fix it (which leads us to (2)). > > Regarding (2) – were you just talking about images? Or do we want to add a > mechanism to fs to address other potentially tricky browser rendering > situations as well (like maybe cross references, variables, entities, conrefs, > OOP . . .)? > > My reason for asking, if it’s just image paths, I agree with you that the > solution is easy. I have no qualms about, for example, breaking fs into a pair > of attributes. We could have fs-element and (optionally) fs-path: > > <segment> > <source>Science is <ph id="1" /> good.</source> > <target > fs="p">科学还是不错 <ph id="1" > fs-element="img" fs-path=” big-happy-smile.jpg” /> > 的。</target> </segment> > > The only tricky thing I can think of in this case is how to express in XML > Schema that @fs-path can only exist if @fs-element exits. > > I just wonder how far down the rabbit hole we’d have to go if we tried to > solve fs issues for every situation (beyond just images) we could think of. > > Eager for more thinking on this topic, > > Bryan > > -----Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf > Of Yves Savourel > Sent: Monday, October 08, 2012 9:30 AM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs > > Hi Bryan, all, > > > Bottom line, I think fs can be used on *some* XLIFF files in *some* > > situations - but not all XLIFF files for all situations. > > Our trickiest example so far is images. For this example I would say > > if the XLIFF file has a clear way of marking up the images, and if > > rendering images is important for the in context review, then the fs > > writer (using whatever language to decode and render) has a reasonable > > hope to present them in a just-in-time browser rendering. > > To me it's not a matter of scope (how much the fs mechanism should allow > the renderers to do), it's a matter of interoperability (all tools should be able > to use fs when present). Having a "reasonable hope" to be able to access the > proper data is not going to work. > > A mechanism that is defined in the XLIFF specification (core or module) > should not rely on <data> or the skeleton to do something, because the > specification only define a place where to put the original data. > > > > Who knows, reasonable > > markup could exist in the <data> element, or in the skeleton, or in an > > external file. > > But in some cases, where the XLIFF file does not manage the clues > > about the images, or does so in a way that is beyond the fs levers, > > then images are simply off the menu. > > Again, this is my point: if you want the fs mechanism to display images in an > interoperable way, it's easy: add to the fs mechanism a way to store the path > to the image to render. Then tool generating the fs markup can also provide > the images (if it's doable), and the mechanism stays interoperable. > > Cheers, > -yves > > > > --------------------------------------------------------------------- > 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]