Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML Ending Tags not recognized in Word Translation Box #126

Open
FilipKV opened this issue May 7, 2023 · 7 comments
Open

HTML Ending Tags not recognized in Word Translation Box #126

FilipKV opened this issue May 7, 2023 · 7 comments
Labels
enhancement Develop an existing feature ui Any problem related to the User Interface

Comments

@FilipKV
Copy link

FilipKV commented May 7, 2023

It would be great to be able to bold some words in the translation box, so far I was only able to use "strong" or "b" and from that place on to the end of the text everything is bold, regardless of the ending tags "/b" and "/strong"
bold lwt

@HugoFara HugoFara added enhancement Develop an existing feature ui Any problem related to the User Interface labels May 8, 2023
@HugoFara
Copy link
Owner

HugoFara commented May 8, 2023

Hello! I see several problems here, let me break them down.

It is difficult to include HTML elements without the risk of breaking the page itself (vulnerability known as HTML injection). It is already concerning enough that you managed to produce this kind of output 😆

Even using another formatting like Markdown, I'm not sure of your target here. Translations are intended to be very small, do you really need extra formatting?

My last point is about your example. Every slash ("/") is get replaced by "/ " because it is a translation delimiter character. If you want to change that, go to your language settings, and remove/replace the slash character. With that you should be able to use closing tags, but keep in mind that it stays hacky. I may implement a clearer system in the future.

I hope that helps you!

@HenryWales
Copy link

Chiming in about translation and their intended size.

I find it impossible to have very small translations that are of good quality You can do very small if you only get a very general approximation, but there are many words with multiple meanings. Then, the word used to translate one of the meaning can have itself multiple meanings, but only one or some are applicable, so more must be added to make clear which meanings are applicable. You also get a series of letter representing multiple words,, like a noun and an adjective at the same time, or a noun and a verb, or even two different nouns.

It can also be useful to add usage notes, grammatical category, word gender (for languages with word gender)...

@HugoFara
Copy link
Owner

HugoFara commented May 11, 2023

Regarding translations, you can have long translations when necessary, it's not an issue. Just separate the different meanings by "/", ";" or "|" (you can customize these characters in settings, scroll to "Term Translations").

The main goal of LWT is to learn foreign languages by reading, translations are simply a small help to your understanding. I do not think it will be a great feature to add more complexity to translations, as it will only divert users from the initial target.

That being said, I know some users really like to add a lot of details to translations, I am still considering whether to use a rudimentary Markdown, I will let this issue open until I make up my mind!

@FilipKV
Copy link
Author

FilipKV commented May 11, 2023

I totally understand what you're saying, and I'm grateful for what you've done so far. It is your project and you have your vision of the direction in which you want it to go.
About long translations, using them is really intuitive for me (I read and hover over a word and bam, there are all possible meanings. And btw, hovering with a mouse is much better than having to click - like in Lingq, that I use for German and Spanish). The reason I suspect you are against long translations and explanations is the aspect of LWT that offers spaced repetition with flashcards. I imagine it would really slow the reviewing process if the cards would contain that much text. But I don't use flashcards. I try to read as much as possible and get my spaced repetition from that (and if I'm confused about the meaning of the word, for example in a new context, I hover over it and find the appropriate meaning).
I found a solution (more of a hack, really) by setting Dict1 to link to my local folder in which I create subfolders with text files of corresponding words (only some that are ambiguous and have many meanings and possible contexts) so that when I click on Dict1 for the word, that folder is opened and I click again on a txt file of that word and the explanations, translations, notes contained in it are displayed (I also sometimes add an mp3 file of the pronunciation to that folder).
That being said, maybe it could be possible to add another field for notes that would serve that purpose. (that feature exists in Lingq already).

@HenryWales
Copy link

Yes, long translations are bad for the built-in testing, but good translations with explanations are worth more than using built-in testing.

I don't want to use built-in testing, but for me to consider it usable it would need at least a way to save which meaning is appropriate in a sentence, and have only this show up when testing. But that's not worth the work. Other "fill the missing word from the translation" systems work because they use already translated sentences. Testing also automatically changes a word level. It's more accurate to set the level by hand. Testing can't account for understanding well one meaning but having trouble with another meaning.

@HugoFara
Copy link
Owner

The reason I suspect you are against long translations and explanations is the aspect of LWT that offers spaced repetition with flashcards.

Hello! My answer is not related to testing, it is true that long translations make testing bad, but users are responsible for there own way of learning. So let's not talk too much about tests, it's another topic and I would be happy to discuss it somewhere else 😄

I create subfolders with text files of corresponding words (only some that are ambiguous and have many meanings and possible contexts) so that when I click on Dict1 for the word, that folder is opened and I click again on a txt file of that word and the explanations, translations, notes contained in it are displayed (I also sometimes add an mp3 file of the pronunciation to that folder).

I am sincerely amazed by your hackyness 😆

maybe it could be possible to add another field for notes

That is a good idea, I usually like to search about the etymology of words, and stuffing every bit of information works, but it can get quite ugly. I am making a new issue at #128 to keep it in mind.

Testing can't account for understanding well one meaning but having trouble with another meaning.

I agree with that, but I do not feel that improving the built-in testing is a good solution, as LWT is a reading app and other free, open-source alternatives like Anki will always be better.

@HenryWales
Copy link

HenryWales commented Jul 7, 2023

I'm coming back to this now, as I'm getting more issues related to translation lengths.

Hello! My answer is not related to testing, it is true that long translations make testing bad, but users are responsible for there own way of learning.

Is it because you think it risks diverting user attention away from reading the texts, as you hinted at before? I wonder what's your reasoning. It certainly depends a lot on personal preference and goals. Managing definitions can take the focus away from reading.

In any case, I'm getting ballooning definitions for some words that change meaning depending on another word that's not right next to them (so it's not possible to use multi-words to fix the issue). Think of how 'look' changes meaning in "I looked this up" or in "She looks down on him". This can change things dramatically, and it's easy to go over the 500 character limits sometimes.

I don't think the underlying issue is easy to address. Additional parsing for complement words in a definition and in a sentence to hide irrelevant parts of the definition would benefit me, but that seems like too much work and complexity for my niche use case. So I want to ask:

  • Are there significant downsides in increasing the 500 characters limit? Outside of those inherent to having to find the relevant part of a long definition, of course.
  • Which files should I change to increase it? Is editing files enough?
  • Would there be particular precautions to take later when updating LWT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Develop an existing feature ui Any problem related to the User Interface
Projects
None yet
Development

No branches or pull requests

3 participants