Jump to content

Recommended Posts

  • Level 5*

Windows? Mac? Android? iOS? Web?

In the Windows and web versions, you can certainly add misspelled words to their respective dictionaries. On Windows (and the web, too, I suspect), you cannot directly edit the dictionary, at least easily, as it's not a text file.

Link to comment
  • Level 5*
1 hour ago, ivanyoung007 said:

Windows 10
I accidentally added "recieved" to the Dictionary and I want to remove it.

Ah, OK. Don't know how to do that. That would be nice to have. I looked for a bit on the web but didn't see anything promising. Evernote uses the Chromium Embedded Framework (CEF) to manage note editing, and that also handles the spellcheck functionality; the dictionary uses the format that the CEF imposes. So you might try digging around on "remove word from Chromuim CEF dictionary". You'll get hits on Chrome, but that's the web browser, and I don't believe that it shares a dictionary with CEF-based applications.

Link to comment

I saved a note about editing EN's dictionary in 2017. 

Essentially you could edit the 'user.dic' file (the dictionary).  The user.dic file in 2017, was located "C:\Users\<username>\Evernote\Dict\user.dic"   ....and it worked great when I made some changes/ tested it back then.   But now in 2019 I can't find it...maybe you can.

EDIT*  Sorry I should have read my note further... because a year later, in 2018, @jefito is quoted as saying "For Windows users, as I understand it, user.dic is no longer used as the dictionary file, due to the underlying framework that Evernote uses. The dictionary that they use is in a binary format, and not generally user-editable. "

Link to comment
  • 5 months later...
  • Level 5

Hi, and welcome to the forums. These forums are user-to-user; though Evernote staff may look in, this is not a way to address them directly. However, there are feedback and feature request forums, such as this: https://discussion.evernote.com/forum/224-evernote-for-windows-requests/, and it would be a good idea to add this request there, if it doesn't already exist.

Some background, though: Evernote broke this a year and a half ago, when, as @cswilly succinctly said, "The dictionary file is stored: C:\Users\<<USER NAME>>\Evernote\LocalStorage\Custom Dictionary.txt. Sadly, you no longer can edit words into the text file. Some goofball of a programmer added a checksum_v1 to the file." I.e., manually editing the file causes the checksum to fail; and as many have observed, there's no editing function built into the program. Here's the post; the whole thread is worth reading:

Since you're a Plus user, @Tomdej, you could send in a support request, and at least get the latest state of their thinking on this. Since the editor is being redesigned in many respects, maybe they'll fix this. Or maybe not.

Link to comment
  • Level 5

My go-to method of accounting for all computer problems these days is: Google screwed it up. A number of things in Evernote got worse instead of better with CEF 3, as I recall. <rant> I truly cannot understand why anyone would think that a simple word list--that's all it is--would need a checksum. What's the very worst that could happen? Programmers are (no offense to anyone here) rarely word people, and anything about a program that has to do with manipulating words should be checked with an English major. </rant>

Link to comment
  • Level 5*
29 minutes ago, Dave-in-Decatur said:

rant> I truly cannot understand why anyone would think that a simple word list--that's all it is--would need a checksum. What's the very worst that could happen? Programmers are (no offense to anyone here) rarely word people, and anything about a program that has to do with manipulating words should be checked with an English major. </rant>

That's a gross generalization, and not at all representative of a lot of the developers I've worked in my 35+ years in the biz, many of whom were indeed "word people". Flip side, of course, would be claiming that English majors are generally not numbers/logic people, so you oughtn't rely on them to produce anything sensible about software design/development. See how that works?

It's possible that the design of the word list was intended eventually to support such things as pluralization, case endings, and the like, something that a simple word list might not be as well suited to. Hard to tell, unless you want to dig in and plumb the depths of CEF change logs (https://bitbucket.org/chromiumembedded/cef/commits/branch/master) (I don't).

Fact of the matter is that the spellcheck dictionary is an artifact of the CEF system, of which Evernote is the consumer; the user is the consumer of the Evernote application. The dictionary is not necessarily meant to be user editable, and that being the case, its format could validly be determined to be the business of the CEF library, and not in user space. The fact that at some point, someone figured out that you could hack the dictionary, well that's cool and all, but nowhere is there any contract between user and CEF that that should be the case. As the user-facing part of the equation, it's up to Evernote to provide a UI for dictionary editing, and they did provide a way to add new words -- just like in Google Chrome, btw. If users want a way to edit or remove entries, then they should ask for that (and they are, and it's a valid & useful request). But to rant about things that were never meant to be a public part of the system is a different kettle of fish.

It's like the folks hereabouts who figured out how to hack in a different colored background for the text editor by modifying the executable. Clever detection, sure, but not guaranteed to work in any other version of Evernote before or after (if I recall correctly, it did for a while, then something changed, and it had to be re-hacked. Well what did they expect? There's no contract between Evernote and its users that its internal logic/processes will remain the same forever. In those cases, if it breaks, too bad. If it seems serious enough, Evernote should consider changing their UI/UX. That's what we do where I work; sometimes we make the change, sometimes not.

Ultimately, my take would be that Evernote offer a full system for adding, removing, or editing words in the dictionary. That way, the format of the dictionary could change, for whatever reason, without any expectation on the part of users to go under the hood to get what they want. If they do, it's on their own lookout.

Link to comment
  • Level 5

@jefito, my apologies for any offensive generalizations. I should have known better.

I'm perfectly happy to blame Google for this, Google, from a user's perspective, has a remarkable track record of half-***ing what it puts out for public use. Anyone who's used Google Calendar for a long time knows that, though they've made some nice improvements lately.

If you're eventually, some time, whenever, going to make your dictionary amenable to pluralization and case endings, that's a nice idea, but marvelously hard to implement in English (and not easy in any natural language). So (if that's the reason, which is only speculation), until that remote date, why not wait to put in the checksum until it will accomplish something useful? In any case:

Quote

The dictionary is not necessarily meant to be user editable

That, dear friend, is my point. Why isn't it? It's of the nature of a user dictionary to need to be user editable, since users (not being hardware) sometimes rethink a decision, or just make a mistake.

I agree that it was on Evernote to provide a user capability to edit the dictionary, and, for that matter, to spell-check an entire note, which I believe also disappeared with CEF3. They had a lot to do just to make the editor functional under CEF3, I know; and now they've shifted gears to the major editor upgrade, which I hope (though I don't know) may be more independent of the vagaries of other people's programming.

I see a very large difference between being able to edit one's personal dictionary/word list, an utterly trivial but valuable procedure, and monkeying around with Evernote's executable code. I don't consider editing my word list to be a hack by any stretch of the imagination. Perhaps this is just a difference of perception.

BTW, Evernote and Google are not alone in this obscuring of users' control over their own words. I also use Scrivener, which is built on the Qt framework. And, whether because of Qt or whatever, Scrivener stores its list of auto-corrections In the Windows registry, where users have even less possibility of manually editing mistakes.

Link to comment
  • Level 5*
17 hours ago, jefito said:

The dictionary is not necessarily meant to be user editable

In its current incarnation it's clear that was the decision.  Problem for some users is that it used to be editable, and take aways are never fun.  Casting errors in concrete doesn't help matters.

I'm with @Dave-in-Decatur on this one, why not have it be editable?  Rhetorical question to be clear.  Can't fathom the logic personally.  Really not that big a deal to get the dander up though.  🤷‍♂️

  • Like 1
Link to comment
  • Level 5*
33 minutes ago, Dave-in-Decatur said:

That, dear friend, is my point. Why isn't it? It's of the nature of a user dictionary to need to be user editable, since users (not being hardware) sometimes rethink a decision, or just make a mistake.

The user dictionary -- or specifically, the list of user additions -- should absolutely be editable. The fact that you cannot make deletions is something that Evernote should provide, and if you want to know the answer, you should ask them rather than ranting (your word) about a file format change. In computers, there very often a distinction between a concept or abstraction (i.e., a user dictionary) and its representation (a text file on disk, a binary file, a group of registry entries, whatever). This is the case here. Evernote should provide the ability to edit the former, but is under no obligation (indeed, isn't even in control of) providing a user editable file that represents the user dictionary. See the difference?

Just because the dictionary file representation was at directly editable at some time doesn't mean that there was any guarantee that it would be in the future, unless that's made explicit by the developer, which as far as I can tell, didn't happen. So the file on disk is evidently not meant to be user modifiable any more, for whatever reason (and your guess would be as good as mine as to why, though my experience tells me that such changes are usually done for a reason, and not at the capricious whim of some "goofball programmer"). If and until someone dives into the CEF change logs and figures out why the change was made (if that's even recorded there), all of the derision, fist shaking, etc. is coming from a place of lack of knowledge of certain facts. Maybe the changes were indeed made on whimsy, but nobody here actually knows that.

So sure, people will go on mucking about under the hood with undocumented files, tweaking the registry, hacking the executable, etc. Fine. But there's no contract between the user and the developer that those things will work in the same way in future releases. It's fun and cool, and useful,to find hacks for things you  want to change -- and I'm writing someone who spelunks the registry myself - but I know better than to have expectations about the future-proofedness of under the hood hacks. 

1 hour ago, Dave-in-Decatur said:

BTW, Evernote and Google are not alone in this obscuring of users' control over their own words. I also use Scrivener, which is built on the Qt framework. And, whether because of Qt or whatever, Scrivener stores its list of auto-corrections In the Windows registry, where users have even less possibility of manually editing mistakes.

So hmmm, there is industry precedent for this sort of arrangement.

Link to comment
  • Level 5*
52 minutes ago, CalS said:

In its current incarnation it's clear that was the decision.  Problem for some users is that it used to be editable, and take aways are never fun.  Casting errors in concrete doesn't help matters.

Assumptions ("hey, this is just a text file, I can just edit it myself") are easy to make, but not always warranted. It was an assumption on the part of certain users that the file format would never change, but there was never any contract between users and the developer about the file format. Reality bites, sometimes.

Link to comment
  • Level 5*
1 hour ago, Dave-in-Decatur said:

If you're eventually, some time, whenever, going to make your dictionary amenable to pluralization and case endings, that's a nice idea, but marvelously hard to implement in English (and not easy in any natural language). So (if that's the reason, which is only speculation), until that remote date, why not wait to put in the checksum until it will accomplish something useful? 

Oh yeah, missed this.

So sometimes, when there's no contract about a particular artifact of a program (file format, registry entry, etc.) a developer will make changes that provide a prelude to making future changes, because there's no expectation that anyone outside will be consuming it directly. And maybe due to scheduling and prioritization issues, the actual changes/improvements aren't made right away (or at all). Them''s the breaks, because the program has already moved on, and the format is different, and it shouldn't affect anything except the program.  People who make assumptions about artifacts of an application can be met with a rude surprise when things change. But there was no contract here. *shrug*

But on the topic of pluralization, case endings,and other linguistic delights, here's a page that discusses the Chromium approach, or at lease serves as a starting point for how Google thinks about such things: https://www.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries. Interesting stuff.

 

Link to comment
  • Level 5*
14 minutes ago, jefito said:

Assumptions ("hey, this is just a text file, I can just edit it myself") are easy to make, but not always warranted. It was an assumption on the part of certain users that the file format would never change, but there was never any contract between users and the developer about the file format. Reality bites, sometimes.

Assumption was warranted in the past as it wasn't an assumption, longevity was an assumption for sure.

Kind of makes one, or me anyway, yearn for an OS level dictionary that all apps use that is editable.  No more adding the same word to email, Word, Evernote, Google Docs ......

  • Like 2
Link to comment
  • Level 5*
15 minutes ago, CalS said:

Assumption was warranted in the past as it wasn't an assumption, longevity was an assumption for sure.

Sure: That it was a simple text file was a fact, that it would remain one was an assumption.

16 minutes ago, CalS said:

Kind of makes one, or me anyway, yearn for an OS level dictionary that all apps use that is editable.  No more adding the same word to email, Word, Evernote, Google Docs ......

In Windows? Roger that. 

Link to comment
  • Level 5

@jefito, I apologize again for making generalizations about programmers, and for quoting someone else's derisive term. I have not been shaking my fist, and I used "<rant>" in a way that I thought would indicate a semi-humorous, if slightly sour, intent. Clearly I caused you some serious offense, and I really am sorry for that, since I respect all the good work you do around here for other users.

You keep using words like "contract" and "obligation," which I have not used. Obviously software changes; I don't expect permanence. I do expect things to make sense. Ultimately, maybe, CEF's spelling system will make sense. (I didn't realize it was the same as Hunspell. Thanks for that link. I've seen other reports of problematic behavior on the part of Hunspell.) I do not think it makes sense to lock down the user dictionary even if (which we do not know) this is done in prospect of eventually having improved functionality. Frankly, I think that this gives some support to my idea that the people who made this decision were not thinking of how users actually need to use this function. And knowing that the course of programming seldom does run smooth is even more reason not to make things inaccessible for the moment in the assumption that that moment will not be long.

For (I hope) the last time, I apologize for giving offense. I am not interested in a prolonged dispute.

Link to comment
  • Level 5*
2 hours ago, Dave-in-Decatur said:

I apologize again for making generalizations about programmers, and for quoting someone else's derisive term. I have not been shaking my fist, and I used "<rant>" in a way that I thought would indicate a semi-humorous, if slightly sour, intent. Clearly I caused you some serious offense, and I really am sorry for that, since I respect all the good work you do around here for other users.

Fair enough, and for the record, I also respect the work that you do in the forums: you help a lot of folks hereabouts and you often tackle stuff that I wouldn't. Sometimes communication gets a little sideways on the web, if if I misread your feelings as being more overwrought than were meant, then you have my apology as well.

2 hours ago, Dave-in-Decatur said:

You keep using words like "contract" and "obligation," which I have not used.

Sure, those are my words, and they stem from my experience in the software development field. To my mind, when you make software, there is -- or ought to be -- some form of understanding that some elements of an application are for use by the end-user, and some are not. The UI is an obvious case of what's clearly in the user area. Scripting languages, and the like, the same. Flip side: registry settings, undocumented files, the actual executable file(s), those are on the developer side. To me, there's an implied contract that the user keep to their side, where we'll do our best to maintain stability of UI and operation,  and not muck with things on the developer's side, because the latter are apt to change. So a contract, not in the sense of something that's legally binding, but nor enforced, but something that gives some measure of guarantees to the user as to where it's safe to change things (user options or settings) and where it's not. If it's a gray area or not documented publicly, we can clear that up if asked. 

As a software user myself, I *want* to go through the app's UI to do things; I don't want to be poking around in the registry or external files unless it's absolutely necessary. The registry is a terrible end user UI, and will give you no information about what are good changes and what are potentially dangerous ones. Ditto for external files.

2 hours ago, Dave-in-Decatur said:

Obviously software changes; I don't expect permanence. I do expect things to make sense.

Stuff on the developer side doesn't need to make sense to the end user; they need to make sense to the developer, because presumably, they're in position to understand what their intended use is.  Some developers are happy to explain why changes are made, some not so much. In this case, it'd be "go ask Google", since it was their change.

2 hours ago, Dave-in-Decatur said:

I do not think it makes sense to lock down the user dictionary even if (which we do not know) this is done in prospect of eventually having improved functionality. Frankly, I think that this gives some support to my idea that the people who made this decision were not thinking of how users actually need to use this function. And knowing that the course of programming seldom does run smooth is even more reason not to make things inaccessible for the moment in the assumption that that moment will not be long.

To me, the dictionary file was on the other side of the line; indeed the fact that it became essentially a binary format is a clue to how the developers viewed it, and that's probably why it was deemed to be OK to change. Maybe they didn't know, or never expected that users would hand-edit it. Or maybe that caused a problem somehow, and it was made binary to make it easier to keep prying fingers out. We don't know.

It's unfortunate that it broke some user's workflow, and also if people lost their edits when the changeover happened, but it seems unlikely to get changed, so it's a case of "be careful what you tinker with" if it's not explicitly deemed appropriate by the developer. Or, in the old saying, "Caveat hackor"...

Link to comment
  • Level 5
13 hours ago, jefito said:

To my mind, when you make software, there is -- or ought to be -- some form of understanding that some elements of an application are for use by the end-user, and some are not. The UI is an obvious case of what's clearly in the user area. Scripting languages, and the like, the same. Flip side: registry settings, undocumented files, the actual executable file(s), those are on the developer side. To me, there's an implied contract that the user keep to their side, where we'll do our best to maintain stability of UI and operation,  and not muck with things on the developer's side, because the latter are apt to change. So a contract, not in the sense of something that's legally binding, but nor enforced, but something that gives some measure of guarantees to the user as to where it's safe to change things (user options or settings) and where it's not. If it's a gray area or not documented publicly, we can clear that up if asked. 

As a software user myself, I *want* to go through the app's UI to do things; I don't want to be poking around in the registry or external files unless it's absolutely necessary. The registry is a terrible end user UI, and will give you no information about what are good changes and what are potentially dangerous ones. Ditto for external files.

 

13 hours ago, jefito said:

To me, the dictionary file was on the other side of the line; indeed the fact that it became essentially a binary format is a clue to how the developers viewed it, and that's probably why it was deemed to be OK to change. Maybe they didn't know, or never expected that users would hand-edit it. Or maybe that caused a problem somehow, and it was made binary to make it easier to keep prying fingers out. We don't know.

So then I think our real differences are two: first, is the user dictionary (not the main dictionary, but the list of new, often specialized terms or proper names that the user needs in their work) on the developer side or the user side of the line? (And I agree that there should be a line.) I see it as on the user side, since it is basically the user's creation, the developer only providing the tools necessary to create it within the software.

Second, if users have a legitimate need to create, update, and maintain that list of their specialty terms, how should that be done? I'm not actually saying that they should be given direct access to the list's representation on disk to edit, though if that list is a simple list of words, I don't have a problem with that. They just need to be given some access, and if the developer decides that direct access to the disk data is too risky, then they ought to provide an interface within the program to add, modify, or delete words in that list. In this case, I'm not sure whether that should have been Google's job, and they didn't think of it or get around to it yet, or it should have been Evernote's job, and they were too busy catching up with CEF3 and then starting the new project of unifying editors across platforms.

The end result is the petitions in this and other forum threads: it's our list, let us maintain it, however it seems best to the developers to arrange that. For closers, here's the dialog that my favorite research word processor, Nota Bene, provides to let users modify their dictionaries (plural--it's possible to have several). NB's philosophy has long been to let its fairly sophisticated user base do lots of customization, including directly editing the file on which this dialog is based; and then do the necessary tech support if users goof it up. Perhaps my familiarity with this admittedly outlying approach is what has shocked me so much about how Evernote has made this difficult-to-impossible. If I could (as in fact I once did before CEF3), I'd copy my list from NB over into EN. Nowadays, and evidently for the foreseeable, that's impossible, and it does make EN harder to work with--although still overall a fantastic tool for my purposes.

image.png.c373f17817883163ff62179d892b5132.png

Link to comment
  • Level 5*
1 hour ago, Dave-in-Decatur said:

So then I think our real differences are two: first, is the user dictionary (not the main dictionary, but the list of new, often specialized terms or proper names that the user needs in their work) on the developer side or the user side of the line? (And I agree that there should be a line.) I see it as on the user side, since it is basically the user's creation, the developer only providing the tools necessary to create it within the software.

I'm OK on disagreeing on this point (and don't want to belabor it further), but more importantly, I'd like to emphasize that from my side, we're all good now.

To the stuff about an actual editing interface, just allowing you to do what could be done previously, i.e., add or remove individual items from a straight list would be sufficient. Really, you're looking for ways to remove actually misspelled items, since you can add new items via the standard note editor. Perhaps the UI could include a way to import a simple list in, as well; that would be handy. Beyond that, working in affix rules would be extra credit, and probably overkill for most Evernoters. And if they could automatically turn 'teh' into 'the', and 'Evernotoe' into 'Evernote' while I'm (mis)typing, that would be ok by me. :) 

  • Like 1
Link to comment
  • Level 5*
1 hour ago, AndreasM said:

What's the point of this very academic discussion?

To make Evernote better.

What's the point of your useless comment? Sorry I read your post -- you're back on 'Ignore'. Again.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...