Filter to look up in dictionary tiddlers

#1

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[]).

I did find a workaround like this:

\define translate() [all[]] :map[[‹dictionary title›]getindex<currentTiddler>else<currentTiddler>]

{{{ [[‹index name›]subfilter<translate>]

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?

Have a nice day
Yaisog

#2

What’s wrong with

[<dictionary-title>getindex<index-name>]

IMO it does not matter if it is the other way around? Can you describe your problem a bit closer?

#3

You should also have a closer look at the view-widget and the transclusion-widget. Both of them can access indexes. https://tiddlywiki.com/#TranscludeWidget:TranscludeWidget%20ViewWidget

#4

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.

#5

@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.

#6

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…

Filter to check if an input item is contained in the parameter list
#7

For handling indexed items also look at the text reference with ##, you can use replaceable parameters in macros to assist

\define get-index(tiddler index) {{$tiddler$##$index$}}

Or in filters `{tiddlername##indexname}` or `{$tiddlername$##$indexname$}`
  • Just to give a clue, not tested recently
#8

Right, that’s another possibility, but I’m trying to stay away from macro text substitutions unless they are the only way…

#9

Fine, what I was also pointing to, was the text reference to an index. No macros required.

{{tiddlername##indexname}} and in filters

  • {{$:/palettes/Vanilla##alert-background}}
  • {{{ [{$:/palettes/Vanilla##alert-background}] }}}
#10

Right. But since the look-up index is generated as a result of a filter and not known in advance, this syntax cannot be used.

#11

Thats is when you use the approach @pmario suggested.

#12

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.

just my thoughts.

1 Like
#13

@pmario: You make perfectly valid points.

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.

1 Like