<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>Looking at deprecated API usage in Okteta, I came over the use of some use of I18N_NOOP2 as well. The use-case there though seems pretty fine to me, porting to I18NC_NOOP will complicate the logic without further need, as the context is the same for all strings in the given array, and always would be:</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">static constexpr const char* longTypeNames[static_cast<int>(PrimitiveDataType::END) + 1] = {
            I18N_NOOP2("data type", "bool (1 byte)"),
            I18N_NOOP2("data type", "signed byte"),
            I18N_NOOP2("data type", "unsigned byte"),
            I18N_NOOP2("data type", "char"),
            I18N_NOOP2("data type", "bool (2 bytes)"),
            I18N_NOOP2("data type", "signed short"),
            I18N_NOOP2("data type", "unsigned short"),
            I18N_NOOP2("data type", "bool (4 bytes)"),
            I18N_NOOP2("data type", "signed int"),
            I18N_NOOP2("data type", "unsigned int"),
            I18N_NOOP2("data type", "bool (8 bytes)"),
            I18N_NOOP2("data type", "signed long"),
            I18N_NOOP2("data type", "unsigned long"),
            I18N_NOOP2("data type", "float"),
            I18N_NOOP2("data type", "double"),
            I18N_NOOP2("data type", "bitfield"),
        };</pre></div>

<p>used by some</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">return i18nc("data type", longTypeNames[static_cast<int>(type)]);</pre></div>

<p>Porting to I18NC_NOOP would mean having to make the table an array of struct {context, text}, and extracting both properties from the table. More runtime cost and complicated logic to read. Which I find cumbersome. I would prefer to have a I18NC_NOOP_STRIP available.<br />
Let's have a warning in the API dox, to tell people they need to use this carefully instead. But making them having to write more complicated logic like here it not developer friendly.</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>