D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

dfaure added a comment. I don't exactly mind if we resurrect NOOP2 or rename it to STRIP, but STRIP kind of makes sense because the name explicitly says something is being stripped (and the documentation should warn loudly about the risks of doing that). It's a better name than "2" where

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

aacid added a comment. You don't want to accept there's a potential problem with typos and that either using KLocalizedString or forcing you to store the context is the solution? Fine then just undeprecate Noop2, but adding strip that does the same is stupid REPOSITORY R249 KI18n

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

dfaure added a comment. I agree with Friederich. In kio/filewidgets/kfileplacesmodel.cpp (for which you accepted the change in D24970 ) I'm passing the context to the method because I18NC_NOOP forces me to, but then I'm *discarding* this context because:

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

kossebau added a comment. 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. When using the I18N_NOOP, one has to know what you do and when you later

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

aacid added a comment. That's the problem with deprecation warnings, they force you to write better code. You don't like the fact that you have to do it, but at least please acknowledge that having "data type" in one place and then "data type" again in a totally different place just

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

kossebau added a comment. 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

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

mlaurent abandoned this revision. REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D24884 To: mlaurent, dfaure, ilic Cc: aacid, vkrause, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

mlaurent added a comment. Ok thanks. REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D24884 To: mlaurent, dfaure, ilic Cc: aacid, vkrause, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

aacid added a comment. In D24884#553786 , @mlaurent wrote: > So what is the correct fix for my case ? Port your code to I18NC_NOOP REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D24884 To: mlaurent, dfaure, ilic

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

vkrause added a comment. In D24884#552701 , @vkrause wrote: > Seeing things like https://lxr.kde.org/source/frameworks/ki18n/src/kuitmarkup.cpp#0336 I'm wondering if this isn't rather a bug in I18NC_NOOP? That's of course a stupid

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

mlaurent added a comment. So what is the correct fix for my case ? REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D24884 To: mlaurent, dfaure, ilic Cc: aacid, vkrause, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

ilic added a comment. The idea was indeed to deprecate stripping of context, and not only the macro name, for the reason Alber provided. The apparent counterexample in kuitmarkup.cpp is seen only due to macro-within-macro call and the macro expansion order, which is a situation that

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

aacid added a comment. https://phabricator.kde.org/D24898 REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D24884 To: mlaurent, dfaure, ilic Cc: aacid, vkrause, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

aacid added a comment. Discarding the context is bad practice, if you discard it, it's very easy you will make a mistake when you try to i18n the text again and not pass the correct context. I'm against bringing any I18NC_NOOP variant that strips the context. This would also break

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

vkrause added a comment. Seeing things like https://lxr.kde.org/source/frameworks/ki18n/src/kuitmarkup.cpp#0336 I'm wondering if this isn't rather a bug in I18NC_NOOP? REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D24884 To: mlaurent, dfaure, ilic Cc: vkrause,

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

mlaurent retitled this revision from "I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text) It will break code as: struct MessageStatusInfo { const char *text; const char *icon; }; static const MessageStatusInfo..." to "I18N_NOOP2

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)It will break code as:struct MessageStatusInfo { const char *text; const char *icon;

mlaurent created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. mlaurent requested review of this revision. REVISION SUMMARY ...StatusValues[] = { { I18N_NOOP2("message status", "Important"), "emblem-important"}, ... }