Skip to main content
B
berard1-Visitor
1-Visitor
February 25, 2014
Question

Dictionary Removal?

  • February 25, 2014
  • 19 replies
  • 4231 views
I'm hoping this will be an easy one, but I've looked into this a bit over
the years, and have never been able to figure it out.

Our writing incorporates a medical spelling dictionary. This loads in
fine, and is specified in the dcf.

The problem is we also have some internal styles that are getting
overridden by the standard English dictionary. Specifically, our
organization chooses to use "ie" and "eg" without periods. (The English
dictionary corrects them to "i.e." and "e.g.")

I've also tried to explicitly add "ie" and "eg" to our custom dictionary,
but it doesn't seem to override.

Does anyone know of a way to remove these from the standard dictionary, or
some alternative?

- keith

    19 replies

    Show previous replies
    B
    berard1-VisitorAuthor
    1-Visitor
    February 26, 2014
    It doesn't seem to read the aptspell.xml from that directory. I can add in
    custom dictionaries in there that are generated using userdict.exe and
    specifying the dictionary in the Options tag of my DCF, but those entries
    seem to be additive, and do not remove standard terms as the aptspell.xml
    does.


    On Wed, Feb 26, 2014 at 11:01 AM, Lisa Bisson-Read <
    lbisson-read@terraxml.com> wrote:

    > Have you tried putting aptspell.xml in the Arbortext-path
    > \custom\dictionaries subdirectory?
    >
    > From help: The custom\dictionaries path is automatically prepended to
    > the dictionaries path at startup. Putting your user-defined dictionaries in
    > the custom\dictionaries subdirectory makes them automatically available,
    > avoiding manual steps to add them to the path.
    >
    L
    LynnHales1-Visitor
    1-Visitor
    February 26, 2014
    Why not just go into the aptspell.xml and make the changes you want?



    Lynn




    B
    berard1-VisitorAuthor
    1-Visitor
    February 26, 2014
    Lynn,

    The main issue is that we have a couple dozen authors located across 5
    timezones all with varying schedules. Prior to the customized install, we
    used to send out manual "patches" but found that not everyone was
    installing them. Having Arbortext automatically get its latest custom.zip
    on startup has been a great solution to this problem.

    The other thing is this just adds to the list of things that would need to
    be done when someone gets a new computer. Just seems like there should be
    a way I can get it set as part of the normal custom deployment.

    But yes, certainly an option. At the moment, I've sent instructions to at
    least our copy-editors to manually enter the "spell -approve/reject"
    entries manually on the command line.

    - keith


    L
    LynnHales1-Visitor
    1-Visitor
    February 26, 2014
    If you are sending out a 'custom.zip' file add the spell file to the zip.
    The custom changes to spell seems to be something one time. Not saying
    individual users may not be adding, but this would be a baseline to work
    from .

    Just my two cents.

    Now if everyone has access to a common network location, you could place the
    custom spell file there and then somehow enforce having the users set that
    path.



    Lynn


    B
    berard1-VisitorAuthor
    1-Visitor
    February 26, 2014
    Could you elaborate on this? What file, and where in the zip?

    aptspell.xml in custom\dictionaries does not seem to work
    adding items to a custom dictionary using userdict.exe does not remove bad
    suggestions from the "standard" dictionary
    adding "spell -accept/-reject" to a script adds multiple entries to the
    main aptspell.xml

    Are you thinking of some other option?

    (Also, common network location is not always available, as users may not be
    online (eg: travel on a plane))

    - keith


    L
    LynnHales1-Visitor
    1-Visitor
    February 26, 2014
    You mentioned sending out a 'custom.zip' file. I was thinking if you did
    send out such a file you could add the spell file to this distribution.

    Editing the spell XML file could be done in Epic (or an ASCII editor if
    you're really into the dirt).

    You might experiment with manually changing the spell.xml with a combination
    of 'spell -reject' in a script.

    Given the excessive number of unique words in the US DOD, I don't even try
    to use the custom dictionary. I'm just thinking out loud.



    Lynn


    B
    BrianJ1-Visitor
    1-Visitor
    February 26, 2014
    Don't know if my setup is helpful to you or not, but here it is.

    We have the aptspell.xml set by the environment variable to be in our
    custom/appdata directory. That way it is in the custom directory that
    gets set on each user's machine when they start Editor. Editor starts
    from a batch file that sets the environment variables we need. It also
    updates any of the files in the custom directory that have changed.

    The aptspell.xml file only has rejected words, not accepted words. We
    have a custom user dictionary file in the custom/dictionaries directory,
    that provides for words that Editor by default marks as misspelled but
    are correct for the client (a state legislature). The words in this file
    are maintained using a java GUI application (that ultimately wraps ACL
    to actually manage the lists) I created to view, add and delete the
    words. Normal users don't have the ability to manage this list, nor do
    they have the ability to add words using the spell command, as we
    aliased the command and customized the Spell dialog box to allow them to
    request a word be added to the accept list. So calling it a user
    dictionary file isn't really accurate, since it's the same list for all
    users.

    If I remember right, you were looking to have "ie" and "eg" to not be
    marked as misspelled, and for "i.e." and "e.g." to be marked that way.
    In our case, we would add "i.e." and "e.g." to the reject list in the
    aptspell.xml file, and add "ie" and "eg" to the user dictionary file.

    One thing to note about the rejected words list, using a kind of funny
    example from the real world; we had a need for the word "pubic" to be
    marked as misspelled since, despite being a real word, it was often
    being typed in mistakenly for "public" (again, state legislature here,
    so that was a commonly needed word). We needed to account for pubic,
    Pubic, and PUBIC, making sure they were all marked as misspelled. I
    found the only way to correctly do that was to have them in the rejected
    word list in exactly that order (pubic, Pubic, and PUBIC).

    Hope that helps,



    Brian Jensen
    bjensen@bluelid.com



    B
    berard1-VisitorAuthor
    1-Visitor
    February 26, 2014
    Yeah, our custom dictionary has about 390k medical words in it, so I prefer
    not to mess with it directly either, but it does load fast and works great
    once compiled by userdict.

    As for custom... I was referring mainly to Arbortext's ability to
    automatically download the custom directory on load. This is setup by
    creating a custom Arbortext installer, or by modifying the deploy.xml
    located in lib.
    <deploy resource="&lt;br"/>

    This installs custom into some weird folder:
    <userdir>\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1 (or 2, as you
    switch between patches)

    Worth looking at if you ever need that sort of thing for code deployments.




    B
    berard1-VisitorAuthor
    1-Visitor
    February 26, 2014
    Ooh, yes, I think I'll play with this a bit.

    We currently use an env variable set in siteprefs.xml to point to the
    license file:
    <environmentvariables><variable name="PTC_D_LICENSE_FILE"&lt;br"/>value="c:\ptc\license.dat"/></environmentvariables>

    I'm not certain if this will directly help me with our custom deploy, as
    it's in an ever-changing directory of Arbortext's choosing:
    <userdir>\AppData\Local\PTC\Arbortext\Editor\.aptcache\zc\1 or 2

    But it might just default to custom being the relative path, so it's a
    whole new avenue to explore.

    To your point of adding "ie" and "eg" to the dictionary... I think that's
    also a good idea, since that might also help with suggested replacement.

    Thanks, I'll let you know how it goes.

    (On a side note, I have a strong feeling that for our work, PUBIC is
    probably more common/desirable than PUBLIC in most case, ha!)

    - keith


    Terms & ConditionsAccessibility statement