@linonetwo I think the problem you face is a conceptual one, One I faced as well some years ago. Perhaps somewhat like you, I was very familiar with procedural languages. You may be tempted to think the tiddlywiki platform is simply the extension of standard programming, it is not, and it can take a while to see the different approach.
This may or may not help you.
The thing is tiddlywiki is primarily a rending machine. Whatever your TiddlyWiki script, in the end it is converted to html and displayed.
You will see in a number of places it is said that macros (now Procedures) are a form of macro for which substitution takes place.
The render process is in effect the last thing that happens.
A term I use to help me understand tiddlywiki is that part of the render process is to evaluate tiddlywiki script and replace it with the values etc… that it references, then convert it to html to render it.
However when we “program” we want to make use of intermediate values, that is we want to evaluate something to then use it for flow control, deeper logical constructs or as a step towards the final outcome. The thing is the wikitext or markdown, rendering is in someways there to generate a final result once it is displayed.
There are plenty of ways this alternative approach gets hidden from us because of the versatility of variables, widgets and procedures. There are a few where it can confuse us with a programing background.
However despite the challenge, it gives us interesting approach and platform on which to build solutions quickly and effectively with far less stuffing around especially with the “presentation layer”.
Just to make it a little more complex tiddlywikis render process automatically responds to changes anywhere in the wiki, using a sophisticate set of trees I believe, in what they call a fake DOM. This often has the effect of rendering and re-rendering only the parts of the wiki related to any changes. To us programmers it gives a false impression that it is not a rendering engine.
Recent developments go a long way to bridging this gap and they are functions, filtered transclusions and the back tick attributes, because they do “evaluate” filters and attributes before invoking the procedure or widget that uses them.
The most clumsy version of this is the wikify widget, If you learn to do without it, life gets easier.
Like any widget consider that what is inside the widget ultimately will be displayed, and the widget can not itself become the input to another widget.
Feel free to ask further questions.
I will give a direct responce to your examples later, as I have an appointment now.
Note: your \define ariaLabel() <<lingo Refresh/Label>> returns empty for me <<ariaLabel>>
The lingo macro is a helper, to shorten code <<lingo reference>>
Instead of the macro you can use a transclusion, which uses the full path name of the translation.
eg: {{$:/language/reference}} so there is no need for wikify.
In ReactJS or VueJS, a component also can’t be used as input of a HTML param. To make it work, usually we extract the JS from that component to be a normal function, then use function call in HTML param.
The problem in tw is it can’t use both widget and function/procedure in HTML param.
@linonetwo I have to be honest I have read your last comment many times and I don’t have the background to understand the terms you are using. I believe however you are just having problems with attributes to widgets.
seems it still transclude the procedure definition, instead of wikify it.
Also I can’t find a doc about [<lingo "Refresh/Label">] usage, seems there is no a variable in filter expression in the doc… And also no “transclude in filter” in the doc. I know there is [{ xxx }] and [<xxx>] usage, but not sure where I learn it, maybe in the forum?
So all it is doing is prefixing the parameter with the lingo-base but also wrapping it in {{ }} your example returns {{$:/language/Refresh/Label}}
So this is prepared to use as a macro that transcludes $:/language/Refresh/Label
I created the tiddler and put the content content of $:/language/Refresh/Label in its text field.
Now <<lingo "Refresh/Label">> returns;
What is the problem?
The issue here is are the language tiddlers available?
The default language is English but I cant find $:/language/en-GB/reference
Unfortunately I don’t normally use the language system so I need to research it more
I have installed the en-US plugin to see if I can learn more. It does not include many tiddlers, I then installed French which I know a little, it has a lot more tiddlers. I can only see it in French going to the edition here https://tiddlywiki.com/languages/fr-FR/index.html
Looking inside this it just replaces a pile of existing tiddlers via the plugin thus they replace those in the core but only when selected in Control Panel > Basics Near the bottom
When I change languages the $:/language tiddler changes eg to $:/languages/fr-FR I think this is primarily to inform the browser.
Otherwise all language tiddlers can be found with advanced search Filter tab [all[shadows+tiddlers]prefix[$:/language]] there is no $:/language/Refresh/Label in the core or us/French language plugins.
But <<lingo RelativeDate/Past/Months>> returns months ago
OK I see now,
Look inside $:/core/ui/ImportListing
It starts with
\define lingo-base() $:/language/Import/
Then uses thinks like <<lingo Listing/Select/Caption>> in plain wiki text not as a parameter.
And transcludes $:/language/Import/Listing/Select/Caption
Conclusion
The macro or utility sets the lingo-base, then the title given to the <<lingo name>> (lingo macro) and prepends the lingo-base and transclude the result.
Since it is a macro that transcludes, it can only be used as if it were a transclusion and not provided as an attribute.
If you use the lingo macro it will only work if there is a matching tiddler.
I will show a new function to do this in another reply
So It is not $:/language/reference here, it is $:/plugins/tiddlywiki/tiddlyweb/language/en-GB/reference here.
The old language mechanism use shadow tiddler mechanism, languages reuse same title, so new language will overwrite old language. But the new lingo feature is that they exist in different title, so need to use the new lingo macro to route to the correct path. This is all for i18n developer experience.