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

[Friedrich W. H. Kossebau]

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 the given array, and always would be:
  
    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"),
    	};
  
  used by some
  
    return i18nc("data type", longTypeNames[static_cast<int>(type)]);
  
  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.
  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.

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D24884

To: mlaurent, dfaure, ilic
Cc: kossebau, aacid, vkrause, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191028/2a226243/attachment-0001.html>