Hi, Welcome!
Do you have an example of 1 or 2 markdown files, so we can see the structure?
Sure, things can be put in the fields of a tiddler.
There are other things, though, that are better suited in dedicated tiddlers for the purpose of reuse via Transclusions.
For example:
The text for the testimonial by Joe Armstrong exists in a tiddler dedicated to that purpose.
The “Testimonials and Reviews” template could have all of the testimonials existing in the body of that one tiddler. But then it is not possible to have links to any one specific testimonial (because, as you already described, that feature does not exist.)
Better for “Testimonials and Reviews” to just be about the display of various testimonials that exist in their dedicated tiddlers.
My original comment was about content in dedicated tiddlers (for which links are easy), and not about putting content in fields. Content in fields is useful for the purpose of transcluding content, but not useful for links to the content, whereas content in the body of a tiddler is good for both Transclusion and links.
The text between dashes is YAML-formatted frontmatter. That’s the sort of stuff I’d expect to put into a field. The links are in markdown format, but Obsidian also accepts wiki links, and I converted them using a plugin before importing them to TW.
The reason the in-language text looks weird is that the “Romanization”, such as it is, is case sensitive, which won’t work with markdown links (since they’re based on HTML) nor the case-insensitive Windows filesystem. So I had to hack it using the mathematical alphanumeric symbols Unicode block. One of the principle reasons I want to switch to TW is that links are case sensitive.
Here’s a link to the wiki itself if you’re curious.
𝚙𝚛 𝚛𝙳𝙱.md
---
entry id: 712
---
# Pronunciation
short high strong grunt, chuff. chuff, long falling weak whine
# Etymology
[𝚙𝚛](𝚙𝚛.md) (reciprocal coverb) [𝚛𝙳𝙱](𝚛𝙳𝙱.md) (to speak, say)
# Definition
## Verb
To discuss, speak amongst.
# Usage
The topic of discussion may be placed as the object of 𝚛𝙳𝙱. The subject is a plural noun or a noun denoting a group, such as [𝙻𝙼𝚛𝚐](𝙻𝙼𝚛𝚐.md) (moot, assembly) or [𝚛𝙿𝚚𝙿𝙻𝚐](𝚛𝙿𝚚𝙿𝙻𝚐.md) (clergy), or else the other discussion partner may be placed as the object of [𝚙𝚛](𝚙𝚛.md).
𝚛𝙶𝙷𝚐.md
---
entry id: 444
check: false
imported: true
---
# Pronunciation
chuff, long low strengthening growl, short low weak growl
# Definition
## Noun
mech, heavy powered armor
I think your imported tiddlers look fine. The links seem to work.
The only thing that seems to have happened, is that your search function does not work anymore.
I did download empty.html from tiddlywiki.com and I did re-import all your tiddlers from your commonthroat.html into empty.
Save and reload, then the search function worked for me.
I personally would define a modified: 20250518 field for every tiddler. So they are visible in the Recent tab.
See docs about the TW date format for more details.
I personally would not change the text portion. – I would add new fields that may be useful in the future for sorting.
Just some thoughts.
-Mario
Interesting. The search seems to work for me. Everywhere I’ve tried it, on whatever instance of TW, it gives you a list of titles and body text that match your search.
I’m among those who would absolutely go with field-structure. Data architecture is beautiful. Flattening data dimensions into ordered text beneath headings is… not.
I suspect you’ll eventually run into situations where search results will be unmanageably cluttered if you don’t have field-structure… For example, let’s find a word whose definition includes “weak” … Oh no! — weak is part of the text of so many tiddlers because it’s a common string in the pronunciation field! Being able to search within a specific field solves such problems.
Another advantage of creating real data structure from the start is that it’s so easy then to come up with on-the-fly variants to your UI: You can make one template for a quick-reference “glossary” that filters according to some condition of interest and formats each definition with a hanging indent but omits etymology and usage notes, for example, while another template foregrounds usage notes up top, puts etymology in italics at the bottom, etc., ordering the fields and applying nice visually satisfying css to them according to whatever the your purpose requires…
You can get a plugin that helps you search in specific (or any filtered subset of) fields. Here’s one:
EDIT TO ADD: You asked about multi-line fields. Yes, you can absolutely have multi-line and multi-paragraph fields:
and here’s a small demo I made.
Let us know what you decide and how it’s going!
I’ve already run into that problem. I have another lexicon for a different language spoken by the same critters that I started just earlier this year that’s much more of a green field for my TW explorations. The first thing I did was come up with a more compact, and more importantly search friendly, phonetic transcription system, as can be seen here.
Regarding the “put everything in fields” concept, it’s more or less what I was complaining about earlier. Wikitext (rather the HTML rendered from it) is already structured. Why not lean into that structure? Again, TW is by no means the only software guilty of this.
I find fields to be super-powerful in their relation to TiddlyWiki’s filters and templates. But if wikitext structure hits your sweet spot, then I certainly will cease evangelizing for fields!
An approach I use often with data from an external source is to (when necessary) write some code to parse the input format into a convenient representation, then write an additional bit to convert that into JSON tiddlers with title, tags, and text fields plus whatever else seems useful. I tried that with your data.
The JS Code creates JSON tiddlers like this:
{
"title": "HKrqFdqg",
"tags": "lexicon",
"entry-id": "581",
"pronunciation": "long rising strong growl, chuff, huff, late high weakening whine, huff, short low weak growl",
"etymology": "[[HKrg]] (notch) + [[qFdqg]] (ear)",
"part-of-speech": "Noun",
"definition": "ear notch (derogatory term for a firearms enthusiast)"
},
I save the output to a file and drop it into an empty wiki, drag your Hello! tiddler over and, since there is no text content in any of these new tiddlers, add a ViewTemplate that looks like this:
title: viewtemplates/lexicon
tags: $:/tags/ViewTemplate
list-after: $:/core/ui/ViewTemplate/body
<% if [<currentTiddler>tag[lexicon]] %>
<dl>
<$list filter="pronunciation etymology part-of-speech definition usage usage-notes notes note note- related-terms derived-terms lore entry-id" variable="field-name">
<% if [<currentTiddler>has<field-name>] %>
<dt><$text text = {{{ [<field-name>search-replace:g:[-],[ ]titlecase[]] }}} /></dt>
<dd><$wikify name="content" text={{{ [<currentTiddler>get<field-name>] }}} output="html"><<content>></$wikify></dd>
<% endif %>
</$list>
</dl>
<% endif %>
This template is fairly naive, just including a definition list for all the custom fields, in an order I guessed might be close to what you’d want. (It also points out that you have fields of note, notes, and note-, which seems odd!) The resulting tiddlers look something like this:
You can see this result at http://scott.sauyet.com/Tiddlywiki/Demo/Commonthroat.html.
This is far from a complete solution. But it might be a start on the way there.
If it’s close and there’s something in my process you want to tweak but don’t know how, just let me know. The code for the conversions is very clear to me, but could well be obscure, or just gobbledygook to others.
2 Likes
I would be more inclined to use them in the way you suggest if TW made it easier out of the box to work with them. Something like prefixing a search with field_name:value would search for that value only in that field. I know the advanced search can do that, but why push such a powerful feature further up the learning curve? Same thing with not allowing line-breaks in the easy-to-access field entry boxes when creating a new tiddler.
My other issue with using fields for my use case is that fields are not hierarchical. Dictionaries usually distinguish between polysemy (a single word having multiple related meanings) and homophony (two unrelated words that sound the same). Polysemous meanings are grouped under one heading, while homophonous meanings are separated.
I will check that out. I’m currently normalizing those obsidian markdown files precisely to turn them into a single monolithic JSON file using Python.
OK, I’ve reorganized my Outlander wiki to put everything in fields. Now I need to figure out how to make those fields searchable.
I’ve implemented your view template here. It seems to work well. Entering words this way would certainly make porting the lexicon to other software much easier. Still need to figure out how to make them searchable and how to quickly enter new entries. Obsidian’s biggest strong suit was that very little got in the way between my ideas and the page. I didn’t have to think of what button to push to format a level 1 heading or start a table. It was all done right there in the body of the note, without the verbosity of HTML markup.
One difference between my parsing and yours was that I further parsed the definition section to extract the part-of-speech. I think that’s useful, but YMMV.
I would not expect to create a tiddler and add the fields manually. I would create an entry form. Here is a sample, adapted from a question of mine from last year:
EntryForm.json (2.9 KB) (download this and drag the resulting file onto any wiki.)
For searchability, another topic discusses way to modify the default search, although I’ve personally only altered its output. But you can also write a custom search using the search Operator, which allows you to search in specific fields or in all fields.
I’m trying to strike a balance between granularity and ease of entry.
Another thing I hadn’t considered is the ability to track backlinks and missing entries (links to missing tiddlers).
Supporting the argument for fields it is the best way and the skys the limit when searching based on a fieldname and value or part there of.
Although I understand if the content you populate your tiddlywiki was insufficently sophisticated to use fields there will be a desire to search the unstructured content at least until you find a way to improve its structure by moving to fields. The fact is there are a range of methods to enhance search in tiddlywiki so you could possibly use a search method that can check the distance so search for “Etymology and ear” and perhaps ask that they be no more than N characters apart and you will have at least a fuzzy type of search (I dont recall yet where this distance check was but one exists), we can look for it if you want it.
To search the whole wiki based on the content of a given fieldname is trivial, even different partial matches are possible.
- Add to that the ability to filter out based on something like object-type first and you have already applied a scope.
1 Like
How does one set that up? I’m terrible at front end stuff. I’m getting flashbacks to when I tried building an Access database at work. I read a whole textbook on DB design and everything. I loved the back end stuff, like tables and key fields and relationships, but when it came time to building a front end so that anyone besides me could use the DB effectively, I collapsed.
2 Likes
I’m throwing my hands in the air regarding fields. If we’re supposed to put everything in fields, we shouldn’t have design a bunch of HTML forms from scratch to add and look up such tiddlers.
If you’ve truly given up, then ok.
If you’re looking for suggestions, there are people willing to help, but I think we’d need actual questions.
Fields are one way of doing things. I have some wikis where almost everything is handled with fields and templates, and there’s little text content. I have others where I touch almost no fields except for the big-Ts, title, tags, and text. It depends upon my need.
2 Likes
The issues I have are:
- You can’t enter newlines into the standard field entry form when creating a tiddler, making it hard to make field-heavy tiddlers out of the box.
- The search box only searches title and text values, not any of the other fields, making it hard to search for field-heavy tiddlers out of the box.
- The solutions to these problems require a lot of verbose markup.
The example of a tiddler entry form given above, while impressive, is beyond arcane to me. Yes I’ve tried looking up the documentation, but I get confused. It’s the same sort of befuddlement I feel when people try to use YAML as a programming language.
The other big reason I’m moving away from fields is that they’re not hierarchical. I mentioned above that i have to distinguish between polysemy and homophony. The word Dbr can mean both to meditate and to research. That’s polysemy, one word with shades of meaning. B is both the verb to attempt and the preposition from, that’s homophony, two separate words that sound the same. These are indicated differently. Homophony in particular would be hard with fields, as you now have one entry–one tiddler-- with multiple parts of speech, so I can’t just have “partOfSpeech” as a single field.
Don’t get me wrong, TW still succeeds at the stuff that attracted me to it in the first place. It has case sensitive links and it’s very easily sharable, but the learning curve is steep.
EDIT: Oops, I missed the fact that @Springer had already provided a demo of multi-line fields above! I’ll leave this for posterity since I did try to outline the mechanics a little further.
If you would like multi-line fields, this one has a pretty easy fix. Here’s a package you can drag and drop into your wiki to try it out; a basic explanation follows. multiline fields.json (701 Bytes)
The edit widget used for a given field name is controlled by a cascade, as shown below:
Here, #2 shows the default core tiddler that will be used to render each field in the editor. #1 is an alternative that takes precedence over the default (since it appears higher in the list). To make $:/my/ui/EditTemplate/fieldEditor/textarea, I cloned the default tiddler and very lightly tweaked it to use a textarea rather than a single-line input.
As written (and as presented in my sample file above), this will affect all fields in the editor. If I wanted to change only a subset of fields, I could use a filter like
[<currentField>match[long]then[$:/my/ui/EditTemplate/fieldEditor/textarea]]
~[<currentField>match[select]then[$:/my/ui/EditTemplate/fieldEditor/select]]
Then, assuming that I had created $:/my/ui/EditTemplate/fieldEditor/textarea and $:/my/ui/EditTemplate/fieldEditor/select tiddlers containing the appropriate widgets, the long field would be globally rendered with a textarea, the select field would be rendered with a dropdown (based on the one in that template tiddler), and all other fields would use the default input.