obsidian-translate
obsidian-translate copied to clipboard
Fevol
translate selection to selected language directly without having to choose
Currently when one uses the translate selection to selected language command, a modal pops up. Having to click the modal or press return is a pain when doing many translations in a row. I would like a command that just translates directly into the last language used.
Thanks.
Many thanks for the feedback!
I'm thinking of renaming the current Translate selection to selected language into Translate selection (select language), and adding a new command called: Translate selection (specific language).
This command would have an option under the Functionality settings that allows you to set which language it should translate to. The options would be as following:
-
Last language used: every time you execute a translation command, the target language will be saved to the settings, and used whenever executing theTranslate selection (specific language)command - if none is set, it will run theTranslate selection (select language)instead. -
Display language: always translate to Obsidian's display language -
Custom language: always translate to user-specified language
Would this solution work for you? The only problem with this, is that user could get confused between Translate selection (select language) and Translate selection (specific language). I'm not entirely sure how to solve that.
@ksdavidc, I've tried implementing above functionality. Below you can find a pre-release for the feature. Please let me know what you think.
Be aware that it may be quite buggy in places, I'm testing out an unreleased component of the API, and some code could definitely be improved. https://github.com/Fevol/obsidian-translate/files/10387656/translate.zip
Many thanks for the feedback!
Likewise. I think the implementation you are suggesting is quite good, but agree some confusion is possible. Comments below.
I'm thinking of renaming the current
Translate selection to selected languageintoTranslate selection (select language), and adding a new command called:Translate selection (specific language).
"select language" is okay, but I feel it could be better somehow. (for one, the word select and selection are a bit similar, but the difference in meaning is significant.)
Some ideas: Translate selection (choose language via modal) Translate selection (choose language from list)
"Specific language". I considered specified, but I think it falls for the same reason as above. Why not use default? Translate selection (default language)
This command would have an option under the
Functionalitysettings that allows you to set which language it should translate to.
I suggest calling this the default language, or command custom default
I know you use a "default" source and target language for the translation view already. I suggest renaming as follows:
Translation View Defaults:
- Source Language
- Target Language
Global/Hotkey/Custom Defaults:
- Command Custom Default Language
maybe "Hotkey Command Default Language"? not sure if that is accurate.
The options would be as following:
Last language used: every time you execute a translation command, the target language will be saved to the settings, and used whenever executing theTranslate selection (specific language)command - if none is set, it will run theTranslate selection (select language)instead.Display language: always translate to Obsidian's display languageCustom language: always translate to user-specified languageWould this solution work for you? The only problem with this, is that user could get confused between
Translate selection (select language)andTranslate selection (specific language). I'm not entirely sure how to solve that.
Good choice of options. I suggest a 4th option "same as translation view target language". I can imagine wanting to always translate into whatever language is being used in the translation view. Or having a fixed, "command custom" language.
Maybe Custom language could be "command custom language".
@ksdavidc, I've tried implementing above functionality. Below you can find a pre-release for the feature. Please let me know what you think.
Be aware that it may be quite buggy in places, I'm testing out an unreleased component of the API, and some code could definitely be improved. https://github.com/Fevol/obsidian-translate/files/10387656/translate.zip
I appreciate your sending the zip file. Other than using BRAT, I don't know how to use a pre-release...
Okay, I just copied the unzipped folder into a blank vault and it seems to be working. I hope that is the correct way. Instead of hotkey, I guess global might be the word, but global sounds as if it supercedes Translation View....
Tested and working fine. Looking forward to when you have the kinks out because I have need of it!!! Good job!
FYI. I tried copying the unzipped folder into my actual work vault (bad bad bad) and it didn't work. The settings for the various languages were blank pages, but the general settings were okay. It did work in the generic vault, though. Reinstalled the latest release but strange that it worked in one and not the other...
I'm really grateful for all the responses, they help me immensely! Based on your feedback, I've made a newer test version - though some of the other suggestions will take me a while longer to implement. I'm going to be pretty busy with work for the next two weeks, so I'll mainly be focusing on fixing critical bugs whenever they pop up.
Plugin zip with incorporated suggestions: https://github.com/Fevol/obsidian-translate/files/10392143/translate.zip
"select language" is okay, but I feel it could be better somehow. (for one, the word select and selection are a bit similar, but the difference in meaning is significant.) Some ideas:
- Translate selection (choose language via modal)
- Translate selection (choose language from list)
"Specific language". I considered specified, but I think it falls for the same reason as above. Why not use default? Translate selection (default language)
Agreed, Translate selection (choose language) and Translate selection (default language) are much better descriptors for the command, changed them.
I know you use a "default" source and target language for the translation view already. I suggest renaming as follows:
Translation View Defaults:
- Source Language
- Target Language
Global/Hotkey/Custom Defaults:
- Command Custom Default Language
maybe "Hotkey Command Default Language"? not sure if that is accurate.
Personally, I think it is fine if the default target language is used for both the translation view and the target language for the translate command, as they fulfill the same uses. Making them separate would introduce unnecessary bloat to the already rather messy settings.
Though your suggestion of separating the translation view and 'global' settings is very helpful. I'm really not happy with the fact that the current settings are a mishmash of settings that apply only to the 'global translator' (i.e. the one used for the commands), settings that only apply to translation views, and both. I'm going to have to think about this for a while.
Good choice of options. I suggest a 4th option "same as translation view target language". I can imagine wanting to always translate into whatever language is being used in the translation view. Or having a fixed, "command custom" language. Maybe Custom language could be "command custom language".
While it is technically perfectly possible for me to add that option, I'm not sure if it would make intuitive sense to the users: you can have multiple translation views open at the same time, each with a different target language, so how do you determine which one of those to use? The last view that was focused? The last view that actually executed a translation request?
I appreciate your sending the zip file. Other than using BRAT, I don't know how to use a pre-release...
Ah yeah, the zip I've sent you is more of a pre-pre-release, it's faster (& much more convenient) for me to just compile the plugin, than to make a beta release for it.
FYI. I tried copying the unzipped folder into my actual work vault (bad bad bad) and it didn't work. The settings for the various languages were blank pages, but the general settings were okay. It did work in the generic vault, though.
Agh, sorry for that! If you're talking about the Functionality settings having a blank page, that means that an error occurred while loading it. Whenever that happens, make sure to open the devtools (Ctrl/Cmd + Shift + I) to see where it is giving an error, and share it with me.
Please take everything below with a grain of salt. I will be pleased no matter what you do, but now that I am here I'll offer my views directly.
I'm really grateful for all the responses, they help me immensely! Based on your feedback, I've made a newer test version - though some of the other suggestions will take me a while longer to implement.
Thanks. Will try it when I get the chance.
I'm going to be pretty busy with work for the next two weeks, so I'll mainly be focusing on fixing critical bugs whenever they pop up.
No worries. I understand. Take your time. I know it must have sounded like I was rushing you, but I was just expressing zeal...
Agreed,
Translate selection (choose language)andTranslate selection (default language)are much better descriptors for the command, changed them.
Sounds good!
Personally, I think it is fine if the
default target languageis used for both the translation view and the target language for the translate command, as they fulfill the same uses.
I understand what you are saying. For me, the two modes don't quite "fulfill the same uses". My use cases might be unusual, but it might make things concrete if I share them. Bear with me...
- I sometimes create a presentation in English for which I like to have a translation in my text for reference. This doesn't need to be so accurate so a first-order translation is good enough. Also, I have a macro that takes an individual line and copies it and provides a translation underneath my original. The macro calls the command at one point, and because it is a macro having to press enter interferes with the flow in the macro, so it would be nice if there were a command default. Having the command default be my second language is good here.
- Secondly, I often take notes from texts in my second language that I want to translate into English. I usually use the translation view (tabbed into the sidebar) to translate into English, and then I extract relevant information into my notes. Here I repeatedly use the same target (English), so it is nice if my default translation view is into English.
- Sometimes, I create a short report in the target language. Here I am aiming for a more accurate translation, so I try to get a higher order translation. I use the translation view (snapped into my right sidebar) to take my English, translate it, then I use the switch button to bring the translation into the source panel, and then translate again to see how well my translation translates. Rinse and repeat until the original and final are a good match, and I paste the final result into my report. (You know the old joke: Out of sight out of mind -> target -> blind fool) Here I am going back and forth. Being able to do this is what first sold me on this plugin.
Though your suggestion of separating the translation view and 'global' settings is very helpful. I'm really not happy with the fact that the current settings are a mishmash of settings that apply only to the 'global translator' (i.e. the one used for the commands), settings that only apply to translation views, and both.
I see your point. To be honest, I don't understand fully at this point all your settings and it took me a while to suss out that there were even two things involved. That said, I think it clear for me to have two modes, maybe call them view mode and command mode, and each has a target and source default. The symmetry here would ease comprehension. I was originally going to suggest it that way, but then I realized that admittedly the command default source language might not be so useful, since autodetect works. On the other hand, as I keep thinking about possible use cases, it might in cases when languages are mixed in a document and autodetect doesn't work. Again, I think if the settings are symmetrical, then it becomes easy to understand. It is the asymmetry that confused me I think.
Now my gears are turning. This is probably not the direction you are taking, but this is how I think, naively and crudely, and without knowing the details of how it is coded. You should do what is best for you, but I put it out here since it came to me. The guiding principle is as much symmetry as possible.
View Mode source language: options: auto (the default), last with default to auto, display, custom, same as last used other mode1, same as other mode setting2 target: last (tied to the individual window), display (the default?), custom, same as last used other mode, same as other mode setting2
Command Mode source language: options: auto (the default), last with default to auto, display, custom, same as last used other mode1, same as other mode setting2 target: last(? once you decide what that means for command3), display (the default?), custom, same as last used other mode, same as other mode setting2
Target and command are essentially the same, except, the tricky bits (that I see): 1 the workflow here is you start using one mode, then decide to jump into the other mode, but it maintains your state across modes...that could be another name for it, "maintain state across modes" 2 "Same as other mode setting" should only be available in one mode at a time. This would allow both to work identically, but have one or the other be the master. 3Command mode target: last. What does that mean? see below
you can have multiple translation views open at the same time, each with a different target language, so how do you determine which one of those to use?
Good point. I hadn't considered that situation, since I usually have only one view open at a time. I was thinking of a modified 3rd use case from above where I am sometimes going from one language to another for a few rounds, then in reverse for a few rounds in both the translation view and my note document. I was thinking last (hotkey initiated) translation request, in fact, but your point is valid.
If you're talking about the
Functionalitysettings having a blank page, that means that an error occurred while loading it. Whenever that happens, make sure to open the devtools (Ctrl/Cmd + Shift + I) to see where it is giving an error, and share it with me.
Actually, it wasn't the functionality settings, but the settings for the individual translators (all of those). Sorry I forgot check for errors. I was rushing through it as I was trying to get work done at the same time..will do next time. :-)
Was about to send and another thought came to me:
If I were doing this (admitedly :-D I am not) and I was really intent on user-friendliness I would create some presets for different workflows, like the workflows above, and the user could just tick a box in the settings that would preselect all four cases for that workflow. Taking that further, the user could create their own custom modes.... Okay, you must really hate me by now, but really, I mean it all in the friendliest spirit. Don't take me too seriously, take your time, and carry on as you would normally. Ignore anything that doesn't suit you and I will take no umbrage whatever you do. I am already more than satisfied with what you did...
Tried out the second zip. Last used setting worked perfectly for the command and it was great for my workflow. Thanks.
Some observations...though I imagine you are still working on it and maybe it will all come out in the wash.
I expected last used would also do the same for the view mode, but it appears not, at first glance. My expectations could be wrong.... It appears to be using the last language I selected when I "manually selected", not the last language I used....or something. I need to do further testing.
It was odd when choosing "manually selected" to have another setting suddenly appear (sans indentation to show it was a subheading). I wasn't sure what this "manually selected" meant. Did it mean that I would get some kind of an option to choose from when translating (not sure that would make sense), or (as it appears) that I would have to choose from one of the options below...this is the custom default we talked about, I think, but that didn't seem to work for translation view. When I opened a new translation view, I got a different language and it stayed at that language no matter what other languages I used it for. Sorry not a very good explanation. I didn't properly test it, but something was odd.
Again, this is probably just me, but my intuition read the text below the heading as being an explanation of the setting in general, not as an explanation of the particular setting. Because one has to select to see the options, I didn't understand there were other options at first (I thought you had eliminated them somehow). I think this might be confusing for new users.
Okay, you must really hate me by now, but really, I mean it all in the friendliest spirit. Don't take me too seriously, take your time, and carry on as you would normally. Ignore anything that doesn't suit you and I will take no umbrage whatever you do. I am already more than satisfied with what you did...
Not at all! This entire discussion has been a delight to me, and I'm extremely thankful for the time you've spent adressing issues, offering up ideas and describing your workflow. I really cannot overstate how much it helps me with making design choices and what functionality is actually important.
In all honesty: I barely make use of my own plugin when taking notes; the extent of my usage is ocassionaly translating an English term because I had forgotten its meaning in my mother tongue. So whenever I try to implement new commands/features/workflows/..., I haven't the slightest clue as to what the users actually want, or how they would use it. That's mainly why I'm really appreciative of any feedback I get back!
(...) for which I like to have a translation in my text for reference. (...) Also, I have a macro that takes an individual line and copies it and provides a translation underneath my original.
I'm glad that you brought this up, because I've been thinking about how to implement an action/view where the user can compare their original text with the translation (see also issue #34), be it a single selection, or an entire note. Not sure how I would implement it, but one solution (and perhaps the simplest conceptually) is to just add a View original text button next to what was translated before, which will disappear after x amount of new translations were made.
The main issue with this workflow, is that I want to avoid adding any type of metadata to notes, unless I really have no other options. So for comparing translation and original, everything would have to be stored temporarily by the plugin itself.
(Below is a mock-up of how that would look like, in this case, This is a translation of something was some text that would have been translated recently)
Personally, I think it is fine if the default target language is used for both the translation view and the target language for the translate command, as they fulfill the same uses.
For me, the two modes don't quite "fulfill the same uses". (...) I usually use the translation view (tabbed into the sidebar)
You're absolutely right, the two different usages of the default target language setting are not the same, though I should probably clarify what I meant by that. Concretely, the default target language is used in three places:
- Whenever the user executes the
Translate selection (default language)command or clicks the 'Translate' button in the editor context menu, this language will be selected as the target language for the translation - Whenever the user executes the
Translate selection (specific language)command, translates a note, or translates via the context menu, this language/these languages will appear at the top of the selection - Whenever a new translation view is opened, this language will be set as the initial target language for said view, and only then - existing views will never have their target language replaced by the default one
So when I say that they fulfill the same uses, I just meant that in the sense that when the user executes the Translate selection (default language) command, or opens a new translation view to quickly translate a few things, you'd want it to be the language that you're most likely to translate to (i.e the default target language). (So, if the translation view is a core part of the user's workspace & they never close it, then the setting wouldn't matter that much to them.)
I don't understand fully at this point all your settings and it took me a while to suss out that there were even two things involved
I appreciate you saying that, it's a clear sign that the design of the settings needs to be overhauled completely.
I realized that admittedly the command default source language might not be so useful, (...) On the other hand, as I keep thinking about possible use cases, it might in cases when languages are mixed in a document and autodetect doesn't work.
Even when multiple languages are mixed in a document, the autodetect will almost always perform better than setting the source language manually. For text where multiple languages are mixed in, it is a non-trivial (probably impossible) task¹ to properly translate every language individually, and still producing a readable/flowing output sentence.
¹ Unless the languages are separated per paragraph/sentence, where this is a slightly more manageable issue
Again, I think if the settings are symmetrical, then it becomes easy to understand. It is the asymmetry that confused me I think.
I fully agree with you here! I'll definitely take that into consideration when revamping the settings.
View Mode ... Command Mode ... Target and command are essentially the same, except, the tricky bits (that I see): 1 the workflow here is you start using one mode, then decide to jump into the other mode, but it maintains your state across modes...that could be another name for it, "maintain state across modes" 2 "Same as other mode setting" should only be available in one mode at a time. This would allow both to work identically, but have one or the other be the master.
These are very good suggestions. I'll have to try implementing it first to see how it feels, but there are two problems with the 'default language' system that I'll first need to figure out:
- If the user selects a specific language (be it source, or target), there is no guarantee that said language will actually be available for the service they're using. When it is not available, what should happen? Error message? Automatically set to
auto/display language for the source/target language respectively? I've skirted around this issue until now, but there definitely needs to be a proper solution for this - For default source language specifically, it would always be better to use automatic language detection than to select a specific source language. However, the
Bergamotservice does not come with automatic language detection, and I cannot assume that the user would have installedFastText, which normally would implement this.²
² Though, maybe I really should automatically install FastText whenever the user installs Bergamot, that should hopefully reduce the initial set-up confusion.
I expected last used would also do the same for the view mode, but it appears not, at first glance. My expectations could be wrong.... It appears to be using the last language I selected when I "manually selected", not the last language I used....or something. I need to do further testing.
You're right, it indeed keeps using the last manually selected language (defaults are only used on opening a new view). It should be pretty easy to add an option to the translation view's dropdown like: Last used language, though I don't know if that is practically useful, since the only way you would be able to set that the 'last used language', is to execute translation commands - so why use the translation view then?
It was odd when choosing "manually selected" to have another setting suddenly appear (sans indentation to show it was a subheading).
Some very good points! I didn't realize it myself, probably because I'm used to this mess, but it's indeed visually unclear which settings are normal settings, and which depend on another setting being set to a particular value.
For now, I've indented all settings that are considered 'subsettings', but I'll need to find a better representation, since that won't work well on mobile platforms.
I wasn't sure what this "manually selected" meant. Did it mean that I would get some kind of an option to choose from when translating (not sure that would make sense), or (as it appears) that I would have to choose from one of the options below...
Again, this is probably just me, but my intuition read the text below the heading as being an explanation of the setting in general, not as an explanation of the particular setting. Because one has to select to see the options, I didn't understand there were other options at first (I thought you had eliminated them somehow). I think this might be confusing for new users.
I've tried fixing the styling and rewriting the descriptions a bit, it looks like this now:
Admittedly, I struggle a lot with finding concise but clear settings descriptors, hopefully it should be a bit more clear now with the current default language being provided directly in the description, but let me know if (and how) I could improve it further!
As always, here is the zip containing the latest code: https://github.com/Fevol/obsidian-translate/files/10402178/translate.zip
can't give a full response, but looking good. I'll share some thoughts once I can.
Tried out the new zip, then I noticed the update, and went with that. Working fine. I like the settings...putting default at top is very good!
...This entire discussion has been a delight to me, and I'm extremely thankful for the time you've spent adressing issues, offering up ideas and describing your workflow. I really cannot overstate how much it helps me with making design choices and what functionality is actually important.
I am glad to hear that.
...I've been thinking about how to implement an action/view where the user can compare their original text with the translation (see also issue #34), be it a single selection, or an entire note. Not sure how I would implement it, but one solution (and perhaps the simplest conceptually) is to just add a
View original textbutton next to what was translated before, which will disappear afterxamount of new translations were made.
This is cool. It's a nice touch. For me, though, the problem is how do I act on the information in the case of a mistranslation. For example, let's say I click on the button...I see the original text. For me this isn't so useful because I wouldn't be able to detect the discrepancy, but I can see it might be useful.
I am interested in comparing my original text with the translation of the translation. I know it is silly, but it works in my situation. I can think of two ways to get at that. One is in view mode to have an optional/collapsible 3rd window that can be set, when open/activated, to do the second translation. This would allow for tweaking the original to get rid of mistranslations.
I am not sure if something like that could work in your button scenario. I imagined a second (optional) button that would show the second level translation. The user could undo to try again if they want. Of maybe it would copy the 2nd level to the clipboard...isn'T quite clear for me yet.
The main issue with this workflow, is that I want to avoid adding any type of metadata to notes, unless I really have no other options. So for comparing translation and original, everything would have to be stored temporarily by the plugin itself.
I don't understand this clearly. If you think it is relevant, I might need a little explanation of what metadata means in this context.
Personally, I think it is fine if the default target language is used for both the translation view and the target language for the translate command, as they fulfill the same uses.
For me, the two modes don't quite "fulfill the same uses". (...) I usually use the translation view (tabbed into the sidebar)
You're absolutely right, the two different usages of the
default target languagesetting are not the same, though I should probably clarify what I meant by that. Concretely, thedefault target languageis used in three places:
- Whenever the user executes the
Translate selection (default language)command or clicks the 'Translate' button in the editor context menu, this language will be selected as the target language for the translation- Whenever the user executes the
Translate selection (specific language)command, translates a note, or translates via the context menu, this language/these languages will appear at the top of the selection- Whenever a new translation view is opened, this language will be set as the initial target language for said view, and only then - existing views will never have their target language replaced by the default one
So when I say that they fulfill the same uses, I just meant that in the sense that when the user executes the
Translate selection (default language)command, or opens a new translation view to quickly translate a few things, you'd want it to be the language that you're most likely to translate to (i.e the default target language). (So, if the translation view is a core part of the user's workspace & they never close it, then the setting wouldn't matter that much to them.)
I see. I think for me, I would use 1 and 2 and 3 in different ways, for different purposes:
- quickly/directly translating given text in a document, or using it as part of command sequence (via templater, for example)
- situations where I am not using my default/most used language
- situations where I want to examine the output in more detail or where I am not actually trying to insert the translation in my document
My point was that the "default", aka the language I would often use, might not be the same in all 3 cases.
HOWEVER, I fully understand this is overly complicated, and maybe really beyond the scope of what you ought to try to accomplish. It has downsides (is this the metadata you are talking about?), and so I am just dreaming...
I don't understand fully at this point all your settings and it took me a while to suss out that there were even two things involved
I appreciate you saying that, it's a clear sign that the design of the settings needs to be overhauled completely.
IT might be because we've been talking about it so much, but it does seem much better now and the added context you provide is helpful.
I realized that admittedly the command default source language might not be so useful, (...) On the other hand, as I keep thinking about possible use cases, it might in cases when languages are mixed in a document and autodetect doesn't work.
Even when multiple languages are mixed in a document, the autodetect will almost always perform better than setting the source language manually. For text where multiple languages are mixed in, it is a non-trivial (probably impossible) task¹ to properly translate every language individually, and still producing a readable/flowing output sentence.
¹ Unless the languages are separated per paragraph/sentence, where this is a slightly more manageable issue
Point well taken. I wasn't really thinking about trying to translate mutliple languages concurrently. I meant trying to isolate out one particular language. I have once or twice, as you imply, not in general, found it helps if I turn off autodetect...it depends on the service. But you are quite right...at any rate, target is what concerns me.
Again, I think if the settings are symmetrical, then it becomes easy to understand. It is the asymmetry that confused me I think.
I fully agree with you here! I'll definitely take that into consideration when revamping the settings.
View Mode ... Command Mode ... Target and command are essentially the same, except, the tricky bits (that I see): 1 the workflow here is you start using one mode, then decide to jump into the other mode, but it maintains your state across modes...that could be another name for it, "maintain state across modes" 2 "Same as other mode setting" should only be available in one mode at a time. This would allow both to work identically, but have one or the other be the master.
These are very good suggestions. I'll have to try implementing it first to see how it feels, but there are two problems with the 'default language' system that I'll first need to figure out:
- If the user selects a specific language (be it source, or target), there is no guarantee that said language will actually be available for the service they're using. When it is not available, what should happen? Error message? Automatically set to
auto/display language for the source/target language respectively? I've skirted around this issue until now, but there definitely needs to be a proper solution for this
excellent point. I can see how it would get dicey. I think it depends on where in the process we are. For example, if they are in the settings, choosing a default, then I would imagine you would limit to the just the currently avaiable languages. If you are changing hte service, then I think you would have to prompt the user to select a new language? Very ugly. Generally you don'T want ot make assumptions for the user. Would you be able to account for all possible sources of conflict and resolve them all. I see the problem. And that is without even taking into account the logistics of coding it.
- For default source language specifically, it would always be better to use automatic language detection than to select a specific source language. However, the
Bergamotservice does not come with automatic language detection, and I cannot assume that the user would have installedFastText, which normally would implement this.²² Though, maybe I really should automatically install
FastTextwhenever the user installsBergamot, that should hopefully reduce the initial set-up confusion.
What are the downsides of this?
I expected last used would also do the same for the view mode, but it appears not, at first glance. My expectations could be wrong.... It appears to be using the last language I selected when I "manually selected", not the last language I used....or something. I need to do further testing.
You're right, it indeed keeps using the last manually selected language (defaults are only used on opening a new view). It should be pretty easy to add an option to the translation view's dropdown like:
Last used language, though I don't know if that is practically useful, since the only way you would be able to set that the 'last used language', is to execute translation commands - so why use the translation view then?
I think it would be useful in the case where you have a master mode and slave mode. The slave would use whatever the last language chosen was. Another mode would tie them to each other. change the language in one changes the language in the other, but the last used one is the master for the other.
(I think. Maybe I am missing something...)
It was odd when choosing "manually selected" to have another setting suddenly appear (sans indentation to show it was a subheading).
Some very good points! I didn't realize it myself, probably because I'm used to this mess, but it's indeed visually unclear which settings are normal settings, and which depend on another setting being set to a particular value.
For now, I've indented all settings that are considered 'subsettings', but I'll need to find a better representation, since that won't work well on mobile platforms.
It looks good now. On mobile can you put an arrow symbol?
I wasn't sure what this "manually selected" meant. Did it mean that I would get some kind of an option to choose from when translating (not sure that would make sense), or (as it appears) that I would have to choose from one of the options below...
Again, this is probably just me, but my intuition read the text below the heading as being an explanation of the setting in general, not as an explanation of the particular setting. Because one has to select to see the options, I didn't understand there were other options at first (I thought you had eliminated them somehow). I think this might be confusing for new users.
I've tried fixing the styling and rewriting the descriptions a bit, it looks like this now:
Admittedly, I struggle a lot with finding concise but clear settings descriptors, hopefully it should be a bit more clear now with the current default language being provided directly in the description, but let me know if (and how) I could improve it further!
It is much better, and I was probably quibbling too much. It is much easier to understand for me now, so I really appreciate your attention and thoughtfulness on it. I am an amateur and no expert, but you've listened very conscienciously and given my suggestions their full due. I really appreciate, as someone who is using this plugin several times a week, that someone has taken the time to address my complaints so generously and pleasantly. I hope you are having a great day, and am looking forward to seeing where it ends up! Cheers...D
I'm sorry for not being able to reply sooner, it was a pretty busy period these past few weeks, but I'm finally able to spend more time on plugin development again!
I am interested in comparing my original text with the translation of the translation. I know it is silly, but it works in my situation. I can think of two ways to get at that. One is in view mode to have an optional/collapsible 3rd window that can be set, when open/activated, to do the second translation. This would allow for tweaking the original to get rid of mistranslations.
If I understand correctly, you usually translate your text twice, i.e: from X -> Y -> Z, and after translating from X -> Y, you'd like to have the option to open a 3rd text input field to (manually?) do the translation from Y -> Z in, while also being able to see original inputs X and Y?
If so, I maybe have an idea that should be a little bit easier to implement, but also allows that workflow: chaining translation views. Say I have two translation views AX->Y and BY->Z, you'd have the option to chain B to A, essentially linking those two views; this would do the following:
- Changing the target language of A from Y to O, will automatically change the source language in B from Y to U likewise. [i.e.: AX->Y and BY->Z becomes AX->O and BO->Z]
- When translating any text in A, its output will automatically be set as the input for B
Apologies if this is not what you envisioned, this is what came to my head when reading your use-case.
I don't understand this clearly. If you think it is relevant, I might need a little explanation of what metadata means in this context.
In this case, I see metadata as the plugin storing the original text of the translation in some form, such that it can be retrieved at a later point for comparisons/reverting translations/.... It's not strictly relevant per se, just something I'm thinking about if I were to implement a 'Show original text' action at some point.
² Though, maybe I really should automatically install FastText whenever the user installs Bergamot, that should hopefully reduce the initial set-up confusion.
What are the downsides of this?
Not too many, except that I intended for the FastText service to be a separate service, that users can install if they want to do so, though I guess I could provide that option by opening a modal whenever the user installs the Bergamot service, to ask if they also would like to install FastText.
Not sure which of the aforementioned things I'll be implementing for the next update; there are many ideas floating around in my head, plus I'd also like to get started on two other plugin ideas I've had for a while.
- Changing the target language of A from Y to O, will automatically change the source language in B from Y to U likewise. [i.e.: AX->Y and BY->Z becomes AX->O and BO->Z]
- When translating any text in A, its output will automatically be set as the input for B
Yes, very nice.
I don't understand this clearly. If you think it is relevant, I might need a little explanation of what metadata means in this context.
In this case, I see metadata as the plugin storing the original text of the translation in some form, such that it can be retrieved at a later point for comparisons/reverting translations/.... It's not strictly relevant per se, just something I'm thinking about if I were to implement a '
Show original text' action at some point.
Having some kind of stored text memory (like a button that would save the text) available would be useful. One thing I often do is tweak my original text a few times to get the double translation right. Being able to store an original result would help in having a place to return to once I have made my tweaks, to see what I changed, or compare to my original.
... I intended for the FastText service to be a separate service, that users can install if they want to do so, though I guess I could provide that option by opening a modal whenever the user installs the Bergamot service, to ask if they also would like to install FastText.
For me, having it optional is fine is not a problem. People like to have control. Knowing that one difference is that it offers autodetect makes me want to install it, but some might not need that.
These are good ideas, and I'd be excited if you implement them, but let me add that even as it is, the plugin is working nicely for me and I am happy with it. Keep up the good work!