[tw5] Re: [TW5] Esperanto Translation (Alpha)
On Saturday, March 26, 2022 at 12:37:17 AM UTC-7 joshua...@gmail.com wrote: > *There is a kind of symmetry that is lost if you have a sentence taking > about "TiddlyWiki" and then "Vikio"* > The thing is, except for the name "TiddlyWiki", the term Wiki is almost never used. Really, it's not so much a "Wiki" as it is its own thing. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e5ab4543-34bd-40e4-97f3-6e503425e45fn%40googlegroups.com.
Re: [tw5] Major updates to Chromium native file system saver plugin
Brian; >>- *Copy path to clipboard*: If we want to save a tiddlywiki to an >>existing location, as may be forced when reloading the wiki or browser, >> we >>already have the full path and filename available in the browser, it just >>needs to be available to the save as dialogue. >> >> Does this one have any technical barrier for you? Sounds like you have it > figured out. Sounds like a useful approach as long as the tiddlywiki is > loaded from a file url. > The only issue is the user needs to be told and/or reminded they can use crtl-v in the file dialogue. Its a trick and not commonly used, although easy to use. This is why if we can rely on local storage for small changes (no auto-save) and trigger a modal when saving we can present a modal to guide the user and address the need for the button click. > [...] > >> >>- *Custom Target/tab:* If we want to protect against opening the same >>wiki in a tab, one trick is after the first save (knowing the full path >> and >>filename) we can construct a html link with an appropriate target >>attribute, then navigate to that (if possible closing the original tab), >>thus the wiki is now running in a tab with a named target. >> >> What needs to know the full path and filename here? The user will know > and the browser will know, but the functionality running in the web page > (i.e. the tiddlywiki instance) will not know. It only has access to the > filename minus the directory location. The directory location is hidden > from it. > The full path and directory is known by a tiddlywiki loaded from file. If a user stores the full path and filename in a wiki it also known to that wiki (eg store in a cookie) > > The user has the information required to construct the html link you > mention, but the tiddlywiki page does not. > [...] > Unless it is given and stores the full path and filename, however if we have a bookmarklet it can store the the full path and filename including a target tab. Clicking the same bookmark will always open in the same tab avoiding the opening of multiple tabs and the global file:// issues(see next notes) > >>- >> - This should help given the global file:// issues >> >> I'm not sure what you mean here. > Just the "problem" with all file tiddlywikis having access to the same file:// domain. However it could be used for communication between wikis if we wanted. However as a rule we want a file:// tiddly wiki opened only once in a browser (or any browser) so there is not "contention" > >>- *Bookmarklet*: Perhaps extending the value of Custom Target/tab and >>because there is value using it, we can consider the use of a bookmarklet >>both with a target and a payload if necessary. >> >> What do you mean by "payload"? Could you give an example? > >> >>- An example may be so if the user returned to the source site, >>published on the internet the bookmarklette can recall you already have a >>local copy and with a click. When saving from the source URL for the >> first >>time we could prompt the user to use their saved bookmark if they want to >>access their local copy, to not create a new one, or override and >> existing >>one. >> >> I'm not sure how the bookmarklet would know you already have a local copy > The bookmarklet only exists if you created it from a local copy, it contains the link and target but can include a payload ie a tiddler containing details about the local copy. Thus the bookmarklete knows you have a local copy. A trick that can be used is on arriving at an internet site we want to save a local copy we use the existing mechanism to save the local copy, then we can open that copy (ideally closing the internet tab #1). Once you have opened the local copy, you have access to the full path. Now so we do not loose the link to the local copy we can provide a link (we build it and can add a payload) for users to drag into their favorites and bookmarks. #1 - before closing the internet tab - Save a cookie (or more) for that site indicating the existence of a local copy. - When our internet wiki loads it can test for these cookies, and advise the user a local copy exists. - It can then ask ONCE the bookmark to be clicked, dropping the "payload tiddler", then the internet site can also save the full path into the cookie(s) - Subsequent visits to the internet site in the same browser can list all local copies of itself and provide links to its target tab OR allow new copies to be saved locally. I know my replies are somewhat convoluted but this is a somewhat complex problem with substantial features if we can achieve it. I believe we just need a little more tweaking and a strong guided workflow. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop
Re: [tw5] Major updates to Chromium native file system saver plugin
On Thu, Mar 24, 2022 at 11:04 PM TW Tones wrote: [...] > I believe I can add a lot here but there remains a slight technical > barrier for me. > > What I want to see is to minimize user interaction including between > reloads, and when forced interaction is necessary, improve and guide the > user for minimum complexity. Here are a few techniques that may help > overcome the barriers. > >- *Copy path to clipboard*: If we want to save a tiddlywiki to an >existing location, as may be forced when reloading the wiki or browser, we >already have the full path and filename available in the browser, it just >needs to be available to the save as dialogue. > > Does this one have any technical barrier for you? Sounds like you have it figured out. Sounds like a useful approach as long as the tiddlywiki is loaded from a file url. [...] > >- *Custom Target/tab:* If we want to protect against opening the same >wiki in a tab, one trick is after the first save (knowing the full path and >filename) we can construct a html link with an appropriate target >attribute, then navigate to that (if possible closing the original tab), >thus the wiki is now running in a tab with a named target. > > What needs to know the full path and filename here? The user will know and the browser will know, but the functionality running in the web page (i.e. the tiddlywiki instance) will not know. It only has access to the filename minus the directory location. The directory location is hidden from it. The user has the information required to construct the html link you mention, but the tiddlywiki page does not. [...] > >- > - This should help given the global file:// issues > > I'm not sure what you mean here. > >- *Bookmarklet*: Perhaps extending the value of Custom Target/tab and >because there is value using it, we can consider the use of a bookmarklet >both with a target and a payload if necessary. > > What do you mean by "payload"? Could you give an example? > >- An example may be so if the user returned to the source site, >published on the internet the bookmarklette can recall you already have a >local copy and with a click. When saving from the source URL for the first >time we could prompt the user to use their saved bookmark if they want to >access their local copy, to not create a new one, or override and existing >one. > > I'm not sure how the bookmarklet would know you already have a local copy [...] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAO5X8CzTsJzpJBRtmjR9oh8p1kTHTsXSD1nWd%3Dd%2BMbPGZcOgng%40mail.gmail.com.
[tw5] Re: [TW5] Esperanto Translation (Alpha)
Great stuff Joshua – I hope you'll consider contributing your work to the core when you get to a suitable point – we already have a plugin for Interlingua, but it would be fitting to also have one for the original conlang. Best wishes Jeremy On Saturday, March 26, 2022 at 7:37:17 AM UTC joshua...@gmail.com wrote: > Thank you for your replies and feedback. It's a good question. > > I'm not sure if other languages translate it, but there are several things > worth considering: > > *Brand name localisation isn't unheard of.* > > I gave the example of Wikipedia in the post. I've also heard that > Salvation Army shops are actually branded as Salvos in Australia because > that's what the locals call it. > > In both cases, the original brand name is still accessible (and not > un-recognisably different either). > *Even if no other language translated TiddlyWiki, the fact that there is a > word for Wiki already makes TiddlyWiki feel a lot more stilted.* > > TiddlyWiki is a brand, yes, but this is an opportunity to make the brand > more living and dynamic. > > *It may look strange to non-Esperantists but the great thing is that > non-Esperantists will never have to see it. The only people who will see it > are the people who recognise it.* > > (All the urls, macros and code will still be the same) > > *There is a kind of symmetry that is lost if you have a sentence taking > about "TiddlyWiki" and then "Vikio".* > > > All that being said, if the Esperantujo ends up preferring against it, we > can remove that localisation. I don't feel expectationally passionate about > it but I do think it's a nice flair. > > > On Friday, March 25, 2022 at 10:19:03 PM UTC+2 PMario wrote: > >> On Friday, March 25, 2022 at 5:33:38 PM UTC+1 Mark S. wrote: >> >> Do other languages attempt to translate "TiddlyWiki" ? I would have >>> thought that that was a special term that would stay itself in most >>> languages. >>> >> >> I'm with Mark here. TiddlyWiki is a "brand" name and shouldn't be >> translated. >> -m >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/83f47424-ec6a-4949-bcf1-ceb3d6eee356n%40googlegroups.com.
[tw5] Re: [TW5] Esperanto Translation (Alpha)
Thank you for your replies and feedback. It's a good question. I'm not sure if other languages translate it, but there are several things worth considering: *Brand name localisation isn't unheard of.* I gave the example of Wikipedia in the post. I've also heard that Salvation Army shops are actually branded as Salvos in Australia because that's what the locals call it. In both cases, the original brand name is still accessible (and not un-recognisably different either). *Even if no other language translated TiddlyWiki, the fact that there is a word for Wiki already makes TiddlyWiki feel a lot more stilted.* TiddlyWiki is a brand, yes, but this is an opportunity to make the brand more living and dynamic. *It may look strange to non-Esperantists but the great thing is that non-Esperantists will never have to see it. The only people who will see it are the people who recognise it.* (All the urls, macros and code will still be the same) *There is a kind of symmetry that is lost if you have a sentence taking about "TiddlyWiki" and then "Vikio".* All that being said, if the Esperantujo ends up preferring against it, we can remove that localisation. I don't feel expectationally passionate about it but I do think it's a nice flair. On Friday, March 25, 2022 at 10:19:03 PM UTC+2 PMario wrote: > On Friday, March 25, 2022 at 5:33:38 PM UTC+1 Mark S. wrote: > > Do other languages attempt to translate "TiddlyWiki" ? I would have >> thought that that was a special term that would stay itself in most >> languages. >> > > I'm with Mark here. TiddlyWiki is a "brand" name and shouldn't be > translated. > -m > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4ba5d9c5-6617-4030-a3c3-86d351430ef9n%40googlegroups.com.
