In empty:
OK, we’ve all seen this and thought “Oh, that’s quite a few but I guess that’s what it takes”…
…but I just discovered this:
WOW!
Knowing that every tiddler brings with it extra bytes beyond the actual data content, I’m wondering what would happen if this was instead in a dictionary tiddler or some other more compact construct ?
Or what if the tiddlers transcluding these had the strings hard typed instead of the transclusion invocations?
If we used a single dictionary tiddler for all the translated strings then it wouldn’t be so easy to override a single entry. At the moment, any of those translatable strings can be overridden as an ordinary tiddler to change the text. If they were stored in a single tiddler then that mechanism wouldn’t be available, and so we’d have to introduce some kind of cascade to search for language strings through a chain of tiddlers.
But it’s not clear what the benefit would be. TiddlyWiki is designed and optimised for working with large numbers of small items. If we move areas of the design to a different mechanism then we’d have to apply similar optimisations to that new mechanism, leading to duplication. A lot of the elegance of TiddlyWiki comes from applying the same mechanisms to multiple problems, making the internals much simpler. We don’t want to have one custom storage mechanism for palettes, a different one for language strings etc. We get simplicity from the “everything is a tiddler” philosophy.
What about using fields to hold the strings? Would that not be efficient? (I’m frequently tempted to use fields for various cases so I’d really like to understand their pros and cons when contrasting them to full tiddlers, or dicitionaries.) This should at least save some kb’s right? Would it be slower vs using tiddlers?
By the way, palettes are dictionary tiddlers - no!?
(Besides, who overwrites those translatable strings to the extent that this would be a problem?)
Thank you for your thoughts.
The fundamental problem here is attempting to store all the language strings in a single tiddler. That’s what makes it hard to merge language strings from multiple sources. Hence why it’s simpler to have a single tiddler for each item.
Which leads to exactly the restriction I’ve mentioned: it is not possible to change a single palette entry without cloning the entire palette. That’s a trade-off that felt reasonable at the time because palettes are usually created/deployed as a discrete unit.
It’s very difficult to assess the likelihood of a certain technique being used. If a technique is super obscure and only ever used by one person, but they incorporate it within a widely used plugin then the technique itself becomes widely used. So we try to resolve this tension by making a design that is internally coherent and consistent, and tries to minimise the profusion of mechanisms.
That’s not really true for “shadow” tiddlers. See: https://tiddlywiki.com/#%24%3A%2FAcknowledgements … Shadows only contain the minimum needed fields. They don’t use modifier, modified … and so on.
If a second language is imported they will add the “translated text” as extra weight, since the core en-EN language elements can not be removed easily. … Because missing translations would lead to “no text at all”, which can make wikis unusable.
@jeremyruston and @pmario - thank you for your informative answers.
Could you formulate a general “rule of thumb” for when plugin authors should stick to this philosophy? I.e to use individual tiddlers vs data tiddlers or fields. (As it happens, I’m currently working on a plugin and facing this very question.)
Thanks again.
