[Bug 12417] HTML5 is missing attribute for specifying translatability of content

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12417

Christian Buratto <christian.buratto@loquant.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christian.buratto@loquant.c
                   |                            |om

--- Comment #28 from Christian Buratto <christian.buratto@loquant.com> 2011-07-28 20:14:12 UTC ---
Let me add more complexity to this...

A "translate" attribute should be flexible enough to indicate a status change
in the translation requirement. Thinking specifically on the localization
workflow, an author may block the translation of content temporarily, while the
suitable translation for the element is not ready -- but then this translation
might become available, and the tag could allow the translator to ping the
'author' for it. For example:

"translate=URL"

The endpoint on URL could provide an empty string ("no translation available")
or one or more translations available for a specific language.

I know this demands an implementation of a query mechanism on the author's
server, but the gains in quality and productivity might worth the discussion.
Imagine that a web page that contains some terms in English would always be
parsed before serving, and if a translation is found, it will replace the term
before serving. Old pages might be always up-to-date, without long processing
(Your company was bought by another one? All references to its name will be
up-to-date immediatelly.)

Similarly, and more important, this could greatly improve the translation
process. A translator would be allowed to have immediate access to that term's
current state and apply it right away. We can even have the translation tool
suggest the translation -- similarly to what termbases do today, but in a
highly targeted way. If we think about contextual translation, where identical
source expressions may be translated differently according to context ("File"
as an application menu, and "File" as a verb, for example), a unique URL for
each could be of extreme value.

Just to give you more info, usually documentation and UI are translated in
parallel, and frequently you don't have access to the final UI terms that are
mentioned on the product instructions. You could finish the doc translation
just to have to change it later when the UI terms are translated or updated.
With the translate=URL approach, the doc could self-update and reflect with
precision what is shown on the localized application.

Of course, the full power of this approach would only be achieved when
authoring tools allow the writers to easily tag terms, and when this tagging is
integrated and available to be queried, but I am having a glimpse of what is
possible. Since you are discussing the creation of a new attribute, maybe it is
the right moment to aim high.

I bet you can see what this could do to TMs...

Regards.

(In reply to comment #26)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > Would  marking content as non translatable change the elements' contenteditable
> > > attribute to false?
> > 
> > I suppose some tool--at some point of a localization process--may find useful
> > to turn off contenteditable if translate is false.
> 
> We could definitely use a non-translatable attribute in OmegaT (a
> Computer-Aided Translation application), possibly optionally.
> 
> I approve Yves' summary, and I'm in favor of such an attribute.
> 
> Didier

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 28 July 2011 20:14:14 UTC