[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xliff] Embedded XLIFF
Dear Youxuan, > Unique Identifier > ------------------- > In a lot of cases, the unique id is already available > in the primary format. We should allow ref into that namespace. > Example: here is the primary data: > <data resID="123456" >this is my string</data> > the method said in your doc, > <data resID="123456" ld:id = "abcdef">this is my string</data> > I think we should allow this: > <data resID="123456" ld:idRef="@resID">this is my string</data> In my view localization directives would be used only when another mean of providing the information is not already used (or to override the information provided by such other mean). In you example resID is the ID attribute to use for your vocabulary, this information should be known somehow at a higher level, without having to insert it in every single document instance. This actually relate to your last comment about scope. You said, very correctly: "Some directives may apply to the whole document while some other my apply only to the current element and its child elements." I agree and would even hope we can go even higher: Some directives may apply to a whole class of documents, in other word to a schema. Such set of properties associated to a document type, would be said (in some syntax): in this document type the attribute resID of the <data> element is the unique Id. Nor XML Schema, or other schema formats have properties for localization currently. Until it happens, tools will -are already- using their own 'setting file' for each XML vocabulary. Localization directives would be used only when there is need to have information at the document instance level, either because its scope is smaller than the one at the document type or because the information needs to be overridden for a give item. Example: ... <title ld:id="id123">My Title<title> </header> <body> <p id="id456">My text</p> <p id="id457" ld:localize="no">My non-translatable text</p> ... In this XHTML file ld:id is used for <title> because XHTML doesn't have an attribute id for <title>. ld:localize is used only when a given <p> element need to be not translated. All the other information (that <tite>, and <p> are transltable, and that id is a unique ID for <p>) would be define at the content-type level. See an example of such localization properties at the schema level at http://www.opentag.com/xmlprop.htm. Obviously this higher level of information needs to be also standardized. It would make sense to have it as part of the schema syntax, but it could be also defined as a specialized file with just the localization properties information. kind regards, -yves -----Original Message----- From: Youxuan Jin [mailto:yjin@windows.microsoft.com] Sent: Wed, June 12, 2002 2:06 PM To: ysavourel@translate.com; XLIFF list Subject: RE: [xliff] Embedded XLIFF my five coments: Identification of Localizable Parts: ------------------- The loc tool to process the directives (or for any loc process) should work without any knowledge about primary format. This is a very important constraint. Also, no primary format information should be duplicated in the loc directive namespace. Here is the example. BAD: it implies the string is the text content of the element. <data ld:localize="yes"> this is my string </data> GOOD: the xpath provide a standard way to access source string. We can make "./text" be the default when ld:ref is absent. <data ld:ref="./text/" ld:localize="yes" > this is my string </data> Usage of ld: tags, such as ------------------- <p>See the <ld:span localize="no">XML Inclusions (XInclude) Version 1.0 </ld:span> document for more information. </p> can really screw up the validation against the primary format schema if any. It requires the primary schema to import the ld namespace and insert ld tags all over the primary schema. I provided example to illustrate my point before. I hope XML standard body can relax the validation so that tags in different namespaces can always be valid. Unique Identifier ------------------- In a lot of cases, the unique id is already available in the primary format. We should allow ref into that namespace. Example: here is the primary data: <data resID="123456" > this is my string </data> the method said in your doc, <data resID="123456" ld:id = "abcdef"> this is my string </data> I think we should allow this: <data resID="123456" ld:idRef="@resID"> this is my string </data> Identification of Changes ------------------- I don't think it pays off for the complexity of managing changes. Business can always send multiple version of docs if changes are important. Scope of directives (new) ------------------- In order to simplify the creation of xml docs with loc directive, we need to have idea of scopes. Some directives may apply to the whole document while some other my apply only to the current element and its child elements. Come with it is the override rules. Typically, the directive that closer to the target in the primary content should override the directives that farther from it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC