Languages in tinylog
Interesting feedback from « gnuserland » on gemini station:
I feel there is something important missing. I would say language support but basically it would be cool implementing some grouping functionality in order to communicate with specific groups only.
For instance I speak daily three languages hence if I want writing down something in Spanish rather than English and I like to exchange my post only with the Spanish fellows.
But language it is just an example, it would be the same for any specific group you may need to create, but doing just something specific for the language because it is somehow already in the specification it would be cool the same!
My response on station:
That's an interesting topic… Language is part of gemini protocol, at the gemini page level.
Are you suggesting that we tag each entries of tinylogs with language? To be honnest I don't think that would work because it would just make author repeat each time the language for the entry (the date format is already "painful enough").
I would think that user could have entries in any languages, that would be more to the client to ignore unwanted language? Or a user could have 1 tinylog per language if he doesn't want to mix it up…
I'm creating an issue in the RFC project to highlight this, thanks a lot for your feedback :)
IMO the best thing would be to create a different tinylog by language which other users will decide to follow or not.
Create different tinylogs is the quick&dirty workaround for this, and I am totally fine with it.
Since I am not a coder I am quite often prone to think things that may not work at all, however based on Lace script you subscribe to a tinylog with this command:
lace sub nickname url
Now I'll do a refence with the language but it could be anything else...
lace sub [en] nickname url lace sub [es] nickname url
Now when is time to create the tinyblog the mandatory format is the following:
## <Date> <Entry Title> <Content>
But it may be possible adding the language group (only two letters for instance), like this:
## [optional] <Date> <Entry Title> <Content>
The parser will expect to find two hash (##) then an optional two letters + space (%20) if the optional group is missing it will expect than find then:
<Date> <Entry Title> <Content>
If the optional language is missing it shares to all your subscriptions, if the language is specified it shares only with the ones that you tagged with the respective language. Subscritions with missing language receive only message without the optional language.
Going a bit further this may a feature that you might enable or disable, and it could be disabled by default.
Thanks for reading this!
Thanks for the detailed feedback :)
When I think about gemini "simplicity", I think about it in 2 ways:
- technical simplicity, meaning writing tools around gemini should be simple (even a server), so a tool like this around a very small RFC standard should be even simpler
- Usage simplicity, making sure that enforcing stuff on users don't make it overcomplicated. Simplicity, for me at least, also implies ease of read.
It's a bit the same as the discussion around the date format (#1).
For 1., I'm not 100% because it would heavily depends on the tool. For gtl it would pretty easy but not sure about a tool like lace for example.
For 2. This is where I think it gets tricky, because having
## EN YYYY-MM-DD HH:MM TZ My TinyLog entry title The content of my entry
Makes the reading part really ugly (at least for me)… Then think about someone that would want to write an entry with 2 languages?
## EN,FR,ES YYYY-MM-DD HH:MM TZ My TinyLog entry title The content of my entry -- Le contenu de mon entrée -- El contenido de mi entrada
That would be ugly as well… You could argue that if a user wants to write the same content in 2 languages, he should write multiple entries?
But if I follow someone and I want to follow 2 out of the 3 languages he uses, then I'll have the post twice… Except if we link them together but that is wayyyyy to complicated for both user and readability.
For me, there is 2 options for author right now:
- Use 1 tinylog and write entries in whatever language. I would advise to not create new entries for translation but just put the different version in the same entry.
- Use multiple tinylogs, 1 per language.
The good thing about these 2 options is that the author is deciding. But the bad thing is that the author can't ignore entries in non spoken language if the author decide to use 1.
When you "follow" users on social media (or even via RSS feeds), if they put all posts in their rss feeds, you'll see them all too…
But if many users starts to heavily use tinylogs with entries in different language, the timeline can get messy quickly…
IMHO, the best would be tinylog files per language… The same way I would prefer to have different RSS feeds for a blog per language… But that's just me^^
Tldr; I think for me the biggest issue if we start introducing date will be the readability, because as a tinylog author, I still want a user going to my tinylog page directly and not via a tool to have a good reading experience. Tools could hide the language in the title, but not on the page itself
I see your points and I was probabling doing confusion, because I was expecting that from another capsule someone was going to parse the RSS to download only the feeds where his/her capsule might be involved.
I agreed with you that better having separate tinylogs for languages/groups!
Thank you very much for your kind reply!
I think we agreed on this one, no metadata around languages.
Either the author decide to mix them and follower either accept or do not follow.
Or the author create 2 tynilogs.
Happy to re-open it if necessary :]
Deleting a branch is permanent. It CANNOT be undone. Continue?