Spellcheck window issue

[BetterRed]

Originally Posted by KevinH

If it will help, we could change the word "Misspelled" to "Error" or "Wrong" or "Typo" or "Bad" but we have no control over the length of the word chosen by various translators. A more descriptive explanation could be added to a Tooltip.

Just let me know if any of those would be better.

IMO, it's better to be precise, so leave as is or maybe change it to "Missing". In this context using judgemental labels is in itself "Wrong". Misspelling is a legitimate literary device, especially in speculative fiction.

BR

[elibrarian]

Originally Posted by KevinH

If it will help, we could change the word "Misspelled" to "Error" or "Wrong" or "Typo" or "Bad" but we have no control over the length of the word chosen by various translators. A more descriptive explanation could be added to a Tooltip.

Just let me know if any of those would be better.

How about this:



which should keep the three rightmost columns from resizing (which is what this is about, not if it's in any way legitimate or not), at least in the original english version of Sigil.

On any account, I'm all in for anything as short as possible.

Regards,

Kim

[KevinH]

How about "Er?" as BetterRed pointed out just because it is missing from the dictionary does not make it a misspelled word or actual error.

I will see about adding descriptive tooltips that help explain any abbreviations being used.

But I am worried that translators will have trouble knowing how to translate "Cnt", "Lang" and "Err" or "Er?" especially as they will not see them in context when translating.

Hmm ... I wonder if there is another solution to this?

[BetterRed]

Originally Posted by KevinH

How about "Er?" as BetterRed pointed out just because it is missing from the dictionary does not make it a misspelled word or actual error.

How about "Miss." - abbreviation for: Missing (from dictionaries), or Misspelled (for US users), or Misspelt (for OE users).

I've never understood the need for the question mark. The spell checker is informing the user of the words that are not in the dictionaries. Suggest the 'Yes' and 'No' be replaced by '✔' and ' '; so that missing/misspelt words will be more obvious when the Show all words option is checked.

Originally Posted by KevinH

I will see about adding descriptive tooltips that help explain any abbreviations being used?

Be useful to translators too.

BR

[KevinH]

So what does a check even mean? It is not clear to me. The whole purpose of a spellchecker is to help identify potentially misspelled words. The key concept here is "potentially". Thus the current Misspelled? column label that is there currently.

Not sure a check and a blank would mean anything in that context.

So, FWIW, I do not think that is a good direction to go here.

[BetterRed]

I think the one on the left is better, it's from calibre.

BR

[KevinH]

But its column headings are as big as ours. I thought the whole point was to shrink them to free up screen real estate. The difference between a check for Misspelled? and Yes is not the issue. The issue is column header width. We are not changing for the sake of change, we are trying to free up horizontal space.

Either way the check is a no for me.

[DiapDealer]

I'm not really a fan of changing to short, cryptic headers that need to be explained via tooltips. I fear we'll always be chasing smaller columns at the expense of clarity of purpose. Especially where new users are concerned. Nevermind that we might put translators in bind by doing so.

What if we parsed column header text from a purposefully named file in the preferences folder? No file = our current text. I'm just not seeing a large enough use-case here that would justify forcing all users and translators to work with a one-size-tries-to-fit-all compromise.

[BetterRed]

Originally Posted by DiapDealer

I'm not really a fan of changing to short, cryptic headers that need to be explained via tooltips. I fear we'll always be chasing smaller columns at the expense of clarity of purpose. Especially where new users are concerned. Nevermind that we might put translators in bind by doing so.

What if we parsed column header text from a purposefully named file in the preferences folder? No file = our current text. I'm just not seeing a large enough use-case here that would justify forcing all users and translators to work with a one-size-tries-to-fit-all compromise.

How about leaving the headings alone and saving the window's geometry on exit and reinstating it next time its opened… like the main window? I'd set mine like so:



BR

[elibrarian]

Originally Posted by BetterRed

How about leaving the headings alone and saving the window's geometry on exit and reinstating it next time its opened… like the main window? I'd set mine like so:

Attachment 212552

BR

THAT is exactly how I would like it to look – and stay that way!

Originally Posted by KevinH

I thought the whole point was to shrink them to free up screen real estate.

It is, but from my point of view only to prevent the three rigtmost columns from resizing on updates.

Aesthetics aside, how many users will look twice at those column titles after having used the spellchecker a couple of times? I don't – I just get irritated on the eternal automatic resizing. (But I may not be an average user – I've been using Sigil at least since version 0.2.4 )

[KevinH]

So it is not column width but column resizing that is the issue?

If we remember the exact geometry of that table, the next time you start it up with a new book the words themselves may not fit the columns. So that is a non-starter for me.

Perhaps you guys tweaking the translations file is the right approach. I will look if there is a way to fix the size of the last 3 columns only.

[Turtle91]

Originally Posted by KevinH

…I will look if there is a way to fix the size of the last 3 columns only.

That’s what I was thinking might be the best answer.

[KevinH]

Unfotunately, given multiple languages, there is no way to know which Language (translated) takes up the most space.

I will try removing the headers temporarily, doing the resize to contents, and then adding back the headers. That should work when the header is longer than the other column contents, to make that column smaller. Yet size everything else as needed.

[KevinH]

Okay, if I simply move setting the headers until after I have auto resized the columns to their contents I get the following image.

See attachment:

[KevinH]

Would that simple change be sufficient? It allows the actual contents to determine the column final sizes not the header label itself. Any extra space is reserved to column 0 (the Word).