Re: Missing requirment - content format/type

Hi all.

Actually the mapping is a little complex. formatType, as it was described by whoever proposed it, was an indication of the *kind* of item something is (e.g., it is a subtitle), but it applies whether or not something is shown in any broader context.

Context was initially proposed by Christian Lieske and I've talked to him about it but not had a chance to write it up. He envisions a very complex model of different kinds of contexts. One of them actually does correspond to formatType, but the others do not. So we probably can collapse the two categories with formatType as one item in context.

At the same time, I think there is a conceptual value to having simpler data categories rather than complex ones. This is an issue we need to discuss. When we hit something like processTrigger or context (as I describe it), these are hugely complex items. When we see a data category with twenty sub-categories, it starts looking pretty complex to implement. Even if it is just a psychological barrier, we do need to consider how the perceived complexity of these things will be received.

-Arle

Sic scripsit Yves Savourel in May 1, 2012 ad 03:05 :

> Hi Dave, all,
> 
>> The text we currently have in the requirements for 
>> the content data category seems very similar, albeit 
>> a subset of, the values defined for restype in XLIFF.
> 
> I assume you mean the 'context' (not 'content') data category:
> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#context
> 
> You are right indeed, 'context' seems to be what would be mapped to XLIFF's 'restype', not 'formatType'.
> 
> (which leaves us with the question of what exactly is the 'formatType' data category?)
> 
> 
>> Yves, I'm not very familiar with this feature in XLIFF,
>> could you provide a bit more background on where 
>> it used and by whom?
> 
> Essentially that metadata (restype) identifies the type of "resource" where the text is used in the original format. This is easily generated for software-type formats like Windows RC, etc.
> 
> It is used, for instance, to provide a basic context to the translator (e.g. a "help" button and a "help" label on a menu bar don't translate the same in French in some cases; or the translation of a title or caption may require different casing rules in some languages, etc.)
> 
> It is also used to help leveraging translations. If two entries with the same source text have no unique names (resname), then the restype value, if present, may help in guessing which translation should be used.
> 
> In my experience, early on this was mostly used for software formats. Nowadays the difference between UI and document-type files is much more fuzzy and many XML-based formats could provide the element name (or a mapping to the element name to a more standard list) as a good context information. HTML5 is certainly a good example of a more "modern" UI format.
> 
> As for the list of values: I suppose, like for 'domain' or other metadata, we could start with a list of basic values, and have a mechanism to allow its customization/expansion. Ideally we would have the same solution for all lists. I'm just not sure what exactly is the best solution:
> 
> - x- values: its-context="x-mywidget"
> 
> - namespace-like values: its-context="myns:mywidget"
> 
> - an extra attribute to extend the main attribute: its-context="string" its-context-ext="mywidget"
> 
> - something else?
> 
> Cheers,
> -yves
> 
> 
> 
>

Received on Tuesday, 1 May 2012 14:54:01 UTC