@Bnyro hello, thanks for the follow-up!

I didn't know that !define was a feature, I just tried it and that's awesome!

I would prefer to integrate with an existing feature rather than creating a plugin after learning about what you suggested, however, I do believe there is more for your project to benefit from my design than simply a provider.

The existing implementation has potential to improve from a usability & UX standpoint:

• If you're explicitly searching for a definition, it's extra work to expand all the drop-downs to view the content, which is a bit anti-user

• There is no point-of-speech delineation, which can be confusing to map definitions to their semantic context

• There are no examples or linked words which I find to be less accessible, but I also understand the design choice of filtering them for safety

• An entry limit is helpful for visibility as some of the definitions are redundant, which without it requires too much scrolling to view other semantics

• This is a personal preference, but I like the ability to have the card and search results at the same time with a dictionary, and that wasn't something I was able to get working from an answerer alone. I also understand the design choice to limit overhead of concurrent requests

• Maybe it's just a "me" issue, but I find the !define implementation more challenging to read and decipher. Line spacing and separation of categories for establishing a clear visual hierarchy a goes a long way with that:

I agree, your layout definitely has some aesthetic advantages over the current one.

Perhaps it'd make sense to adjust the existing translations template with your suggestions, so that we don't have two maintain two separate templates? This way translations could also benefit from the better UI design :)

I agree, your layout definitely has some aesthetic advantages over the current one.

Perhaps it'd make sense to adjust the existing translations template with your suggestions, so that we don't have two maintain two separate templates? This way translations could also benefit from the better UI design :)

Absolutely! I also completely agree that it would be much easier to converge from a maintainability, and both a backend and UX design perspective. I think it would be great to improve more than just the definitions.

If I'm being honest, I learned about SearXNG a few days ago and set up a server for personal use, but I started looking through the codebase yesterday. I don't have enough experience with it to be comfortable modifying a core feature without understanding the implications. It's for that reason specifically I chose the plugin approach, as it doesn't break anything 😊

With that being said, I'd be happy to help however I can within my "green" understanding of the project, and you’re more than welcome to use any part of my code in whatever way fits best. I just wanted to share my implementation for personal use with the hope that it could be beneficial in some way.

To change the style of the existing translations answer template, you can simply:

1. Create a new file translations.less here: https://github.com/searxng/searxng/tree/master/client/simple/src/less/result_types and insert your CSS code
2. Add an import to import your style here:

   searxng/client/simple/src/less/style.less

   Lines 1166 to 1169 in 2cdbbb2

   	@import "result_types/keyvalue.less";
   	@import "result_types/code.less";
   	@import "result_types/paper.less";
   	@import "result_types/file.less";

   , similar to the existing ones
3. Commit your changes and run make static.build.commit afterwards

To convert your wiktionary code into an engine, you can just create a new file here: https://github.com/searxng/searxng/tree/master/searx/engines and read through the developer documentation: https://docs.searxng.org/dev/index.html. Perhaps this should be fairly simple given the fact that you already implemented this plugin.

If you have specific questions, please don't hesitate to ask. :)

Great @Bnyro, thanks for the suggestions!

I've been digging further into the source and noticed there are already a few dictionary-style providers. I honestly hadn't realized that earlier, very interesting! Just to confirm, are these currently the only engine modules using the Translations framework? I want to be certain of the proverbial blast radius with core changes before considering a design:

• wordnik
• libretranslate
• dictzone
• translated

Additionally, from an architectural standpoint, I'd like to understand your stance on generated HTML. Since you mentioned improving the translation/definition framework as a whole, I'd prefer that any refactor toward an engine should also include the opportunity to bring the existing modules in line with a consistent structure. For example, adopting some of the normalization and layout ideas from my plugin.

To expand a bit on the HTML standardization, my current implementation preserves formatting like bold, italics, and internal links (rewritten as local SearXNG searches). Since most of the dictionary engines already simplify structured HTML, this could be implemented fairly cleanly. If I restrict the rendered HTML in the template for only a handful of tags, does that approach align with your expectations around sanitization?

Finally, I'd like to clarify configuration possibilities. Ideally, it would be great to expose a few small options:

• a toggle to load searches concurrently with any cards (if feasible within the answerer framework, and disabled by default)
• a configurable limit on definition/example entries, defaulting to 5/3 respectively seems comfortable based on my testing

I know scope creep is a common concern and I want to be respectful of that, but at the same time, there are some features like the HTML parsing which would require modifying how the template is rendered, and also, how data is passed into it. So I just want to be clear about where the line is for you on that.

I mainly want to make sure these goals fit within your long-term direction before I start moving pieces around. Let me know your thoughts!

For example, adopting some of the normalization and layout ideas from my plugin.

I have to repeat, the concept behind are the Result Types ..

.. in this concept, a result type like Translations is bound to a html template in the simple theme simple/answer/translations.html and its not intended to bound Translations results to a template define.html

Translations(
    ...
    template="answer/define.html"
) 

On Client side, we have the CSS (aka LESS) https://github.com/searxng/searxng/tree/master/client/simple/src/less

See #5366 (comment)

For example, the WeatherAnswer type ..

HTML template is in

• https://github.com/searxng/searxng/blob/master/searx/templates/simple/answer/weather.html

and the CSS layout of the client is in

• https://github.com/searxng/searxng/blob/master/client/simple/src/less/weather.less

To expand a bit on the HTML standardization, my current implementation preserves formatting like bold, italics,

Don't do it, the engines, plugins and answerers .. the code that produce the BaseAnswers does not decide about rendering, this code returns a result type .. noting more .. you can re-use existing Translations types if the rendering for your results do not need any special UI ..

If you want a UI different from Translations you have to implement a result (answer) type Definitions which is ..

In terms of data structure, this class here is very similar to the type Translations

see my comment above: #5366 (comment)

I hope my explanations have been able to show “where” we want to go... As already mentioned above, this concept of result-types is currently still under development and therefore somewhat difficult to understand .. If I had more time, I would rebuild your PR... However, that would take longer, as I currently have many other unfinished tasks to deal with.

Perhaps you would like to try to restructure the code in this PR yourself so that it fits better into our concept of result types? On the other hand, if you have some time and patience with me, we can also do this together.

@return42 as Bnyro and I were discussing before, we were considering a restructure of Translations as a whole to align with the design motif of my plugin, not to use a custom template. That way, all the Translations type engines could support those features and improve the entire system.

However, your "don’t do it" framing and the way my questions were brushed aside comes across as fairly dismissive, and if your intent is to collaborate as you suggested, I don't feel like my perspective is being heard. My goal was to clarify architectural intent and find a collaborative path forward, and it seems as though you're firmly against the idea of restructuring the Translations template, rendering, or functionality.

I respect that, and that's why I asked about where your scope lies. If that is in fact your stance, I don't have an interest in continuing to work on this. Though, you're more than welcome to use my code.

However, your "don’t do it" framing and the way my questions were brushed aside comes across as fairly dismissive, and if your intent is to collaborate as you suggested,

My english isn't the best .. in the core I offered you my support.

we were considering a restructure of Translations as a whole to align with the design motif of my plugin, not to use a custom template. That way, all the Translations type engines could support those features and improve the entire system.

If you prefer to restructure existing code .. then yes, please consider a restructure of Translations 👍

If you prefer to restructure existing code .. then yes, please consider a restructure of Translations 👍

Okay, great. With this perspective, could you both take another look through my previous comment? I want to ensure that we're on the same page, and that I understand the scope of these changes before proceeding with a design.

Additionally, from an architectural standpoint, I'd like to understand your stance on generated HTML. Since you mentioned improving the translation/definition framework as a whole, I'd prefer that any refactor toward an engine should also include the opportunity to bring the existing modules in line with a consistent structure. For example, adopting some of the normalization and layout ideas from my plugin.

To expand a bit on the HTML standardization, my current implementation preserves formatting like bold, italics, and internal links (rewritten as local SearXNG searches). Since most of the dictionary engines already simplify structured HTML, this could be implemented fairly cleanly. If I restrict the rendered HTML in the template for only a handful of tags, does that approach align with your expectations around sanitization?

Sure, please do so 👍

Finally, I'd like to clarify configuration possibilities. Ideally, it would be great to expose a few small options:

a toggle to load searches concurrently with any cards (if feasible within the answerer framework, and disabled by default)
a configurable limit on definition/example entries, defaulting to 5/3 respectively seems comfortable based on my testing

I think you can do that in a different follow-up PR.

If I restrict the rendered HTML in the template for only a handful of tags, does that approach align with your expectations around sanitization?

Sure, please do so 👍

I don't have a final meaning about the HTML markup. In order to separate data from its representation, we have recently made considerable efforts to remove all HTML tags from the result items of the engines and have begun to build up the result types.

The requirement for an inline markup for paragraph-like types has been on my mind for quite some time:

We could (as suggested above) use a subset of HTML tags for this purpose, but then we would have to agree on which tags are included in this set, how they can be combined, and much more. In my opinion, this approach is wrong because it would mean we would have to start developing our own markup. Another disadvantage would be the presence of a few HTML tags in the strings of the JSON output.

What we need are basic inline markups such as those found here in the reST markup.

For this, we can implement a class CommonMark for str objects with some basic inline markups, similar to the DateTime type to wrap datetime.datetime objects.

Something like (untested) ...

import functools
import msgspec
from markdown_it import MarkdownIt

class CommonMark(msgspec.Struct):
    """String type with some `basic inline markup`_ (CommonMark_)

    .. _basic inline markup: https://docs.searxng.org/dev/reST.html#basic-inline-markup
    .. _CommonMark: https://commonmark.org/
    """

    p: str

    def __post_init__(self):
        # normalize whitespaces to one space
        self.p = " ".join(self.p.split())

    def __str__(self):
        return self.p

    @functools.cached_property
    def html(self):
        """Generates a string with HTML markup from CommonMark (uses markdown-it-py_).

        .. _markdown-it-py: https://github.com/executablebooks/markdown-it-py
        """
        return (
            MarkdownIt("commonmark", {"typographer": True}).enable(["replacements", "smartquotes"]).render(self.p)
        )

In line 137 we can replace the str by the CommonMark from above.

And in the template we replace item.text by item.text.html: