In the context of translating some strings, I came across the need to look up a term in a Data Dictionary (x-tiddler-dictionary) and return the result. Which is what I’d suspect to be one of the natural functions of a dictionary tiddler.
However, I couldn’t find a filter operator that does something like this:
[[‹index name›]operator[‹dictionary title›]]
i.e. that takes an index and looks it up in the tiddler that is given as parameter to the operator, only the other way around (getindex[]).
The :map filter run prefix wasn’t available before v5.2.0, though, so there would’ve been another way? I could imagine setting a variable to ‹index name› and then using getindex[] with a soft parameter, but that seems even more convoluted. Therefore, I’m thinking I might have missed something in the docs. Did I?
No. Previous to the :map filter run prefix we’d have used a temporary variable to handle this.
The construction that @Yaisog is asking for is not interchangeable or equivalent to the current getindex operator. It’s a common problem: it often the case that an operator expects parameters as operands, but that one would like to compute them with a filter expression.
@jeremyruston got it right. It’s a matter of how one generates the items to be looked up. In my case they are the output of a filter run, more particularly a filter that outputs a weekday or month name. The whole thing can be found in this thread.
So, for some date juggling I have a filter that ends with
format:date[DDD]
which will give me the weekday name, e.g. Thursday in an English wiki. I would like to translate this name without changing the wiki language or loading language plugins. The easiest way is to set up a dictionary tiddler for the 15 or so terms that need translation. Ideally, I’d like to have a lookup operator from the OP simply appended to the filter run, like
format:date[DDD]translate[MyDictionary]
to get the weekday name in any language I like. The dictionary to be used could even be put into a variable for greater flexibility.
To get the term to be looked up into the parameter of the operator, I’d need to put it in a variable first. This cannot be done with defines, though, and is thus harder to construct subfilters this way.
Another alternative to :map that I could think of would be to put each word pair into its own tiddler, as in
title: $:/dictionary/Thursday
Donnerstag
and then use the lookup filter. This is how the core does it when needed, I think.
Another example for this would be to check if an input title is contained in a list which itself is saved in a variable, I think. The other way around would simply use match<title> to check if the title stored in is contained in the input list. I believe the current solution for this is :filter, together with enlist[] and match[], which performs the enlisting for each input title, which is probably not very efficient.
This is something I run across every now and then, since I usally save the results of the more expensive operations like search:*[] into variables to keep things running smoothly…
I think that’s only a problem, if users want to do everything within 1 line of filter syntax. IMO that’s the wrong approach. …
I did do that myself, but most of the times after some code iterations it turns out that it has advantages to split up long and complex filter runs into several pieces. It improves debug-ability an most of the time flexibility too.
IMO instead of searching for the “perfect” filter run which does it all, it’s much more productive to have several lines of code which actually work and can be improved in the future.
In the OP I was just wondering if I had missed a filter operator in my search, as I suspected this to be a natural operation for dictionary tiddlers, and very often TW provides the filters for common use cases directly. Before :map and friends such a lookop would not even have been possible with filters alone, but only with additional $let/$set lines, and would thus have resulted in quite convoluted code.
There are probably a few filters out there that could be replaced by more complex concatenation of others. I did post an example of how to work around this particular issue.
Anyway, this was not meant as a criticism of TW’s capabilities or a suggestion of new features. I was simply afraid that I made my filters unnecessarily complex, as I often do.
This function defines a new .translate filter operator that takes the dictionary tiddler as parameter, so it does not have to be hardcoded into a subfilter.
You would make the above definition global and then use it like this: