<table><tr><td style="">kossebau added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D24884">View Revision</a></tr></table><br /><div><div><p>As said, I do not think this would be "better" code. And it's violating a bit the goal of zero cost abstractions, given this adds runtime need which could be avoided compared to the old code.<br />
When using the I18N_NOOP, one has to know what you do and when you later on pass data pointers instead of literals to i18n calls. Thinking people who do that are in general challenged to ensure the proper context call is still used might be challenged in other places before IMHO.</p>

<p>And no, I do not want to do hacks in my own code, that proposal will be ignored. Let's have KI18n provide a nice API for developers, and not get in their way in some halfhearted way to be foolproof.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R249 KI18n</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D24884">https://phabricator.kde.org/D24884</a></div></div><br /><div><strong>To: </strong>mlaurent, dfaure, ilic<br /><strong>Cc: </strong>kossebau, aacid, vkrause, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns<br /></div>