- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Aug 2011 17:15:52 +0000
- To: public-i18n-core@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12417 --- Comment #42 from Arle Lommel <fenevad@gmail.com> 2011-08-03 17:15:50 UTC --- > My general preference would be that the HTML5 document could simply be > localized in place, without having to insert additional state attributes or > value structures. That is, the value of localize= is stable between the source > and target document, and is semantically appropriate. This is certainly the simplest way to handle it and would probably account for 90%+ of the use case needs. Additional state attributes would probably not yield much in the way of advantage since the purpose is really to provide a pragma-type instruction to downstream processes about what to do. In this case the only thing most of them would care about is “do I translate/localize this or not”? In most cases this information would be added by authoring tools with some sort of integrated terminology feature that is flagging non-translatables. The simpler we can keep it for them, the better. The only complication I see right off is knowing whether or not something was already translated, but in most cases MT results will be automatically generated, not published, so this issue wouldn’t normally be a problem. So my vote would be to keep this as simple as possible and treat my idea of indicating whether a page is source or target as a separate, less important, issue. (My guess is that this attribute really would be best handled as a <meta> tag. As far as I can see, the appropriate place to propose my idea is on the WhatWG wiki. Unfortunately (for me), without someone already implementing the idea and endorsing it, the likelihood of it being accepted there is slim.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Wednesday, 3 August 2011 17:15:58 UTC