-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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! |
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)... |
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! |
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. |
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. |
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 am sincerely amazed by your hackyness 😆
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.
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. |
I'm coming back to this now, as I'm getting more issues related to translation lengths.
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:
|
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"
The text was updated successfully, but these errors were encountered: