RE: [ACTION-211] Review Localization Quality Precis for readability from non-localisation viewpoint

Hi Micha,

Many thanks for the feedback.

> - Example 76: There is a typo. It should read “…how to use…”
> - Example 77: Instead of “…how to us …” it should just be “…how…”
> - Example 78: There is a typo. It should read “…how to use…”

I'm too fond of copy/paste... Fixed.


> - Example 81: The formatting of the explanation does not follow the usual layout

I assume you mean why the attributes are not green links? Good question. I'm not sure. They are defined in the markup section and they have their <att> elements in the ODD. I'm sure I'm missing something and Felix or Jirka will, no doubt, enlighten us very soon on what it is.


> Why is there an option to use a relative selector (pointer)
> for the values of the rules elements? What is the benefit 
> instead of just putting the concrete values there?

The global *Pointer attributes are used to allow mapping attributes or elements in non-ITS formats that have the same semantic, so they can be used instead of the ITS native vocabulary and ITS processors can still understand them.

Some data categories don't have them because the information they carry is simple enough to be mapped using a simple rule. For example translate of HTML can be map as:

<its:translateRule selector="//*[@html:translate='yes']" translate='yes'/>

I don't know of any format that provide the same semantics as LQP's, but future formats may find it easier to define their own markup to implement the data category, thus defining the pointers now covers those cases.

At some point it might be a good idea to review all data categories for consistency on this.


> And why are these pointers not supported in the local 
> definition?

Because the idea is that mapping is done at the vocabulary level. If HTML's translate='yes' equals its:translate='yes', it always does. So it can be declared once globally and is not needed locally.


Thanks,
-yves

Received on Friday, 31 August 2012 12:03:03 UTC