Problem with 〜 and with Katakana

[zackalucard]

Hi Kitsun,

1/ I noticed a problem while doing some reviews from a deck I created. Because a screenshot says more than a thousand words, please look at this:

We can see that I have a problem with 〜 that seems to be not recognized.
Do you know how to handle this? Well, the better should be that I only have to write “の一つ”. Maybe an option to add in HTML?
One easy answer could be to create a new field without 〜, but I think it’s not really elegant.

2/ I have a quite similar problem when I write the answer (with occidental characters) while the word is in Katakana. The word is counted as false while the rômaji transformed in hiragana are correct. Any idea?

Feedback:

• After importing some words from an external file, the app says that the importation worked well, but we stay on this page. It should be great to be automatically conduct to the deck we used to import the new words.
• Using a computer, on the words page, if we have too many columns, we can take the up and down scroll only if we go far to the right with the left and right scroll. And it is not convenient (In my personnal case, I have an old laptop, and its pad doesn’t have the possibility to go up and down with the fingers).
• About the same subject of the previous point, one interesting nice feature could be to have the possibility to scroll the screen with arrow keys.

[Neicudi]

Heya!

Edit 2: See post below this one for the solution.

I’ve just tried it myself and it seems that the way the Japanese input converts ~ is 〜 whereas your IME gives ∼ or ~ while entering the value in the card creation popup.

Here’s all of them next to eachother on the forum: 〜～∼~

Here’s all of them next to eachother on kitsun:

So it looks like using the IME on Kitsun somehow converts the second one as another variant than it does on this forum, and also different from how the Japanese Input conversion converts it.

I’ll have to check if there’s anything I can do about that, because I honestly have no clue what might be causing this issue I’ll let you know if I find anything out.

Edit: It could also be another problem, as this is what I personally encounter as the problem when trying it. But I also found the following online:

U+301C WAVE DASH – Codepoints

vs

U+FF5E FULLWIDTH TILDE – Codepoints

They look the same but are actually different characters. It might be that your IME chooses one that is different from the one that the auto conversion input uses. I personally can’t seem to produce either of these in full-width with my IME (on Kitsun) to begin with though

2/ I have a quite similar problem when I write the answer (with occidental characters) while the word is in Katakana. The word is counted as false while the rômaji transformed in hiragana are correct. Any idea?

Is the value for the answer (the correct answer value on your card) also in hiragana? Or is it supposed to be Katakana? If it must be Katakana then you can switch to Katakana conversion by toggling caps lock on while typing into the input field.

After importing some words from an external file, the app says that the importation worked well, but we stay on this page. It should be great to be automatically conduct to the deck we used to import the new words.

Good idea! Noted!

Using a computer, on the words page, if we have too many columns, we can take the up and down scroll only if we go far to the right with the left and right scroll. And it is not convenient (In my personnal case, I have an old laptop, and its pad doesn’t have the possibility to go up and down with the fingers).

I’ve tried to change this in the past, but sadly I could not find a good solution for this problem as it is not a regular table that’s being used. Without getting too much into detail, it’s a virtual scroll list which calculates what to show (for memory purposes) based on the height and amount of the items, meaning that the scrolling will always take place at that part and the scrollbars can’t be shown on the enclosing div.

For the same reason I can’t get the first few columns to stick while scrolling horizontally (like others previously suggested).

About the same subject of the previous point, one interesting nice feature could be to have the possibility to scroll the screen with arrow keys.

I think either this or being able to drag vertically (like you can do on mobile) would be the best solution for this. Drag is already implemented for horizontal scrolling, so implementing drag for vertical scrolling might be easy

[Neicudi]

Okay so I made some progress on the first problem. It seems that one of the backup fonts (Microsoft YaHei) is causing the display issue where ~ stays halfwidth for me. After removing that font from the styling I can now reproduce your issue:

And I can now confirm that the issue is the same as the one I mentioned in my edit above:

The first character is how the input automatically converts it.
The third is how our IMEs seem to input a tilde.

It appears that there is no decent solution for this (as far as I can see) so I’ll just be replacing the "Fullwidth Tilde"s with "Wave Dash"es from now on before checking the answer.

I’ll also remove the backup font that is causing the issues from the styling

So in conclusion, it will be “fixed” in the next update. Sorry for the inconvenience!

[zackalucard]

Hi @Neicudi,

Thanks a lot for your research. I’m glad you found the problem.
To say the whole thing, I have the same trouble with ー (−キロ). I can imagine that it is a similar problem.

For the same reason I can’t get the first few columns to stick while scrolling horizontally (like others previously suggested).

Don’t worry, it’s a fact I noted and I just wanted to make a feedback on it. No big deal

If it must be Katakana then you can switch to Katakana conversion by toggling caps lock on while typing into the input field.

Ok! I didn’t know that, thanks!

[Neicudi]

No problem at all! Thanks for reporting

ー (−キロ)

Seems like the same problem yeah… two different characters which look near identical.

(note that both are different from the −キロ you wrote above though, as this one seems to use a regular halfwidth -)

[zackalucard]

note that both are different from the −キロ you wrote above though, as this one seems to use a regular halfwidth -

Exactly, I noted that. However, I made a copy/paste from my Excel list… Well, quite curious.

[Neicudi]

The fix for this problem should now be live as part of the last update