<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 2013-04-08, at 2:40 AM, Erik Jan de Wit wrote:</div><br><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>And then allow HTML markup in translation values? We could treat them as SafeHtml…</div></div></blockquote><br></div><div>One possible solution would be to define elements that are to define that some elements are always treated as inline instead of needing to declare them by hand.</div><div><ul><li style="font-family: verdana, helvetica, arial, sans-serif; font-size: 12px; line-height: 16px; "><a href="http://www.w3schools.com/tags/tag_phrase_elements.asp" style="color: rgb(0, 0, 0); ">&lt;em&gt;</a>&nbsp;(emphasized text)</li><li style="font-family: verdana, helvetica, arial, sans-serif; font-size: 12px; line-height: 16px; "><a href="http://www.w3schools.com/tags/tag_phrase_elements.asp" style="color: rgb(0, 0, 0); ">&lt;strong&gt;</a>&nbsp;(important text)</li><li style="font-family: verdana, helvetica, arial, sans-serif; font-size: 12px; line-height: 16px; "><a href="http://www.w3schools.com/tags/tag_mark.asp" style="color: rgb(0, 0, 0); ">&lt;mark&gt;</a>&nbsp;(marked/highlighted text)</li><li style="font-family: verdana, helvetica, arial, sans-serif; font-size: 12px; line-height: 16px; "><a href="http://www.w3schools.com/tags/tag_cite.asp" style="color: rgb(0, 0, 0); ">&lt;cite&gt;</a>&nbsp;(the title of a work)</li><li style="font-family: verdana, helvetica, arial, sans-serif; font-size: 12px; line-height: 16px; "><a href="http://www.w3schools.com/tags/tag_phrase_elements.asp" style="color: rgb(0, 0, 0); ">&lt;dfn&gt;</a>&nbsp;(a definition term)</li><li style="font-family: verdana, helvetica, arial, sans-serif; font-size: 12px; line-height: 16px; "><span style="background-color: rgb(255, 255, 255); ">&lt;i&gt; tag is usually displayed in italic</span></li><li><span style="background-color: rgb(255, 255, 255); "><font face="verdana, helvetica, arial, sans-serif"><span style="line-height: 16px;">&lt;b&gt; tag is&nbsp;usually&nbsp;bold</span></font></span></li></ul></div>And maybe even span, although that can be a scary one.</div></div></blockquote><div><br></div><div>I expect this would work well in the majority of cases, and maybe that's all that matters.</div><div><br></div>My concern with this approach is that it moves us from the place where there is a very simple rule ("unless I say otherwise, every textual fragment under a non data-field element is translatable") to a place where we have to list the special exceptions to the rule. Check out the list of inline HTML 5 elements (under the heading "Text-level semantics" here:&nbsp;<a href="https://developer.mozilla.org/en/docs/HTML/HTML5/HTML5_element_list">https://developer.mozilla.org/en/docs/HTML/HTML5/HTML5_element_list</a></div><div><br></div><div>I suppose you could argue we've already broken the ice on special exceptions for placeholder and title attributes.. but this is a much longer list.</div><div><br></div><div>What does everyone else think?</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div style="text-align: left;"><blockquote type="cite">e. I think we should automatically consider placeholder and title attributes as translatable. Perhaps there's a case for allowing end users to override this default in ErraiApp.properties or in an attribute of the @Bundle annotation if we keep it. I'm mostly thinking of custom data-* attributes as a motivation for this.</blockquote></div><div><br></div><div>+1 placeholder and titles need translation 99.99% of the times in my experience.</div></div></blockquote><div><br></div>Turns out this is already working, I was already using it, and I hadn't even noticed. :)</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div></div></div><blockquote type="cite"><div><div>f. It would be kind of us to include a reusable language chooser widget with well-documented CSS classnames. Seems like everyone is going to need one of these.</div></div></blockquote><div><br></div><div>Or at least a way to get a list with the available translations. That way one can wrap them into a template and have them output as a select or a list of links. And when a language is added there is no need to change anything on the client.</div><div><br></div><div>for example:</div><div><br></div><div>@Inject</div><div>private List&lt;String&gt;&nbsp;supportedLocales;</div><div><br></div><div>and then have a template render it.</div><div><br></div><div>@Inject @DataField ListWidget&lt;String, LanguageSelectWidget&gt; langaugeSelectList;</div></div></blockquote></div><br><div>Yeah, that sounds like a reasonable approach too, especially if the "live DOM update" behaviour gets put into TranslationService.setCurrentLocale().</div><div><br></div><div>-Jonathan</div></body></html>