@karelzak if this approach seems like a good way to address the problem, I can propagate to all other tools that would benefit from this feature. What do you think ?

I’d suggest first considering:

• Is the current method of using a sequential search for column names optimal? Would it be better to keep column definitions in alphabetical order and use bsearch() to make it more efficient/elegant? For example, lsfd provides ~100
  columns.
• Currently, --output-all follows the order in which columns are defined. Would it be better to introduce a static array of IDs for the --output-all to control the order?

Translations:

• I’d suggest postponing gettext() calls where possible (for --output name,...). First search for native column names; if unsuccessful, translate with gettext() and search for the translated version.
• Maybe we don’t need to call gettext for everything; call gettext, compare,
  and stop the loop on the first match.

Something like:

static char *translated_cols[  ARRAY_SIZE(infos) ];            
static translated_ncols;              
                                     
size_t column_name_to_id(const char *name, size namesz)        
{                                     
       struct colkey = { .name = name, .sz = namesz };        
       struct colinfo *info;         
                                     
       /* original names */             
       info = bsearch(colkey, infos, ARRAY_SIZE(infos),       
                       sizeof(infos[0]), colkey_cmp());
  
       if (info)                     
               return (size_t)(info - infos); 
  
       /* translated */               
       for (i = 0; i < ARRAY_SIZE(infos); i++) {              
               if (translated_ncols < i) {    
                       translated_cols[translated_ncols] =    
                               gettext(infos[translated_ncols].names);
                       translated_ncols++;    
               }                     
               if (strncasecmp(name, translated_cols[i], namesz) == 0)
                       return i;
       }
  
       warnx(_("unknown column: %s"), name);
       return -1;
}  

Maybe @masatake and @t-8ch have any idea :-)

I’d suggest first considering:

* Is the current method of using a sequential search for column names optimal? Would it be better to keep column definitions in alphabetical order and use bsearch() to make it more efficient/elegant? For example, lsfd provides ~100
  columns.

I agree with this idea for cases where the set of columns is significantly high (15+ maybe). But is this really necessary for something as humble as swapon which contains only 7 columns ? I feel like the effort would outweigh the actual benefits in that case. Nevertheless, I passed all possible columns for lsfd on the command line and the overall time the command took to complete was ~24s. There are probably not many frequent cases where this would be an issue but I guess the worst possible case somehow warrants a bsearch.

* Currently, --output-all follows the order in which columns are defined. Would it be better to introduce a static array of IDs for the --output-all to control the order?

Indeed this can be helpful for --output-all and also the default output columns, as I assume that --output-all is a mere extension of the default output column order, hence the same static array can be used, where for default output you would simply delimit the iteration. As an example:

static const int all_columns[ARRAY_SIZE(infos)] = {
	COL_PATH,
	COL_TYPE,
	COL_SIZE,
	COL_USED,
	COL_PRIO,
	COL_UUID,
	COL_LABEL
};

/* --output-all */
case OPT_LIST_TYPES:
			for (ctl.ncolumns = 0; (size_t)ctl.ncolumns < ARRAY_SIZE(infos); ctl.ncolumns++)
				ctl.columns[ctl.ncolumns] = all_columns[ctl.ncolumns];

/* default output */	
if (ctl.show || (!ctl.all && !numof_labels() && !numof_uuids() && *argv == NULL)) {
		if (!ctl.ncolumns) {
			while (all_columns[ctl.ncolumns] != COL_UUID) {
				ctl.columns[ctl.ncolumns] = all_columns[ctl.ncolumns];
				ctl.ncolumns++;
			}

But this would assume that the order in which we define columns is not the same order we want the default/complete output to appear in the terminal. That would be applicable for cases where we need a bsearch implementation for example in lsfd since that will be in alphabetical order.

Note that this is not about swapon; the goal is to implement something we can use for all utils where it makes sense. I guess @cgoesche selected swapon because the original report is against swapon.

The other question: do we need to support translated column names as an argument for --output colname,...? Would it be enough to support translated column names only on output, but keep them in the original (English) on the command line?

Ad bsearch(), the arrays are static and we fully control them, so reducing the number of strcmp()-like calls makes sense from my point of view, especially if it's trivial. But yes, it's nothing important :)

I am not positive about translating the column names in the output, as we use these column names in the -Q filter expressions.

In Japanese, "ファイルディスクリプタ" is the translation for "FD".
I don't want to write lsfd -Q 'ファイルディスクリプタ == 1' on the command line.

What I like about lsfd is that I can use the output directly in the filter expression.

Hmm, -Q is a good point. Currently, in the tools we use scols_table_get_column_by_name(), and if the column name does not match the names used with -Q, it will not work, and addressing this would require more changes to the tools.

I agree that for working with columns on the command line (and in scripts), it is better to avoid translations in favour of portability.

@cgoesche Perhaps the best for now is to postpone this ;-)

If a terminal supports tooltips, we can utilize them for showing translations.

Is there any sequence for the tooltips, or is it just OSC8 hyperlink, but without a URI prefix (file:// ...) ?

Tooltips seems like a reasonable alternative, I'll look into the possibilities and report back here 👍

Doesn't this however mean that we'll have to gettext() all columns destined for output before formatting it to OSC8 for example ?
@karelzak I know you were kind of against that gettext() machinery in the initial phase of the program. Any opinion on this ?

Doesn't this however mean that we'll have to gettext() all columns destined for output before formatting it to OSC8 for example ? @karelzak I know you were kind of against that gettext() machinery in the initial phase of the program. Any opinion on this ?

Maybe we can use the column description as a tooltip rather than translate the column name. The descriptions are already translated and may provide useful information, including in English. (I mean the text used in --list-columns/--help.) In some cases, the column names are abbreviations, and the full descriptions are usable for everyone.

Currently, new columns are created with:

   cl = scols_table_new_column(table, "NAME", width, flag);  

I think it would be best to extend libsmartcols and add:

   scols_column_set_description(cl, _("this is a description"));

The library would internally use OSC8 when printing the header if the description is non-NULL. It currently uses ul_fputs_hyperlink(uri, link, tb->out) to print links; something similar will be necessary for tooltips.

Details: in libsmartcols/src/print.c:print_data(), you can detect when it is printing the header (ln is NULL), read the description from the column (cl), and generate the sequence, etc. See how the function handles URIs.