When I spell-check and add to dictionary, LibO fails to add any word with a right single quote (’) as the apostrophe. If I change the right single quote to a straight one ('), LibO will add the word, plus it will remove the red underlines from any matching words with right single quotes too. OOo behaves like this too last I checked.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
An EasyHack should have been checked by developers and thus is confirmed regardless of age. Moving back to NEW from NEEDINFO again. Sorry for the hassle.
I edited the summary as it happens not just with some words containing apostrophes (curled?) but containing hyphens and probably other characters.
Oh: Hyphens are OK, so back to just curly apostrophes. (Ignore last comment.)
It does happen with hyphens, randomly. (?)
Deteted "Easyhack" from summary
Please consider: <http://wiki.documentfoundation.org/BugReport_Details#Version>
Duly noted. It occurs in 3.6.4.
I wanted to fix this bug, so I tried to reproduce it both on 4.1.0.0.alpha0+ (Build ID: fb7bb64f5b0abe48146498d2f05713a61e4a706) and 3.5.4.2, but didn't succeed. What I did was: * open a new document * write O’Briaaan (using ’ aka U+2019) twice * write O'Briaaan (using ' aka U+0027) twice * notice that all four words are underlined * add "O’Briaaan" to the dictionary The result is: * O'Briaaan is added to the dictionary (with U+0027) * all four words are now marked as correct Am I missing something? Thanks.
(In reply to comment #9) > Am I missing something? Changing to NEEDINFO.
Scott, why not provide some examples, so others are clearer about what we're dealing with?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Removing comma from whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
I think this report relates to how the dictionary files store their information and how this information is interpreted. It may actually be an enhancement request. Here are the grep results from some of the dictionaries in v4.1.3.2: $ grep -e "'" /opt/libreoffice4.1/share/extensions/dict-en/en_AU.dic | wc -l 1410 $ grep -e "’" /opt/libreoffice4.1/share/extensions/dict-en/en_AU.dic | wc -l 0 $ grep -e "'" /opt/libreoffice4.1/share/extensions/dict-en/en_GB.dic | wc -l 925 $ grep -e "’" /opt/libreoffice4.1/share/extensions/dict-en/en_GB.dic | wc -l 0 $ grep -e "'" /opt/libreoffice4.1/share/extensions/dict-en/en_US.dic | wc -l 390 $ grep -e "’" /opt/libreoffice4.1/share/extensions/dict-en/en_US.dic | wc -l 0 My goodness, us Australian's really do like to shorten everything, don't we? Even the main system dictionaries here under Crunchbang 11 x86_64 show the same pattern: $ grep -e "'" /usr/share/dict/american-english | wc -l 26226 $ grep -e "’" /usr/share/dict/american-english | wc -l 0 $ grep -e "'" /usr/share/dict/british-english | wc -l 26245 $ grep -e "’" /usr/share/dict/british-english | wc -l 0 Presumably this is because, as reported in comment #9, the auto-correction of U+0027 contextually to U+2019 is handled by the word processor. To add to what that comment states: $ cat .config/libreoffice/4/user/wordbook/standard.dic OOoUserDict1 lang: <none> type: positive --- No entries. Now I enter the text as indicated in comment #9 and add the term to the dictionary: $ cat .config/libreoffice/4/user/wordbook/standard.dic OOoUserDict1 lang: <none> type: positive --- O'Briaaan Spell check is as indicated in comment #9. Now I edit the dictionary to manually alter the character from U+0027 to U+2019: $ cat .config/libreoffice/4/user/wordbook/standard.dic OOoUserDict1 lang: <none> type: positive --- O’Briaaan The result is that the spell check is no different. All four instances are marked as correct. It is possible that this bug may actually be an enhancement request to get the dictionary facility of LO to detect these differences i.e., mark U+0027 as incorrect and U+2019 as correct. Whether that is even possible would require a developer to comment on. In any case it would seem a huge request.
Thanks for the detailed explanation! Why would O'Brian be wrong when O’Brian isn't? I'd say that this is a feature, not a bug. (By the way, this behavior probably comes from hunspell, LibreOffice's spell checker).
(In reply to comment #15) > Why would O'Brian be wrong when O’Brian isn't? Well "O'Brian" in either form is probably not a good example as it is a name and so unlikely to be in a dictionary. A better example might be "shouldn't" (common contraction) or "'cos" (contentious slang contraction) in either form. The more general point about the case of U+0027 being invalid and U+2019 being valid is however the main one at the heart of this report. In spelling-correction terms (final manuscript copy) I can understand the desire to change all U+0027 to U+2019, but I am not sure the entire way the dictionary sub-system works needs to be altered to cater for *storing* the U+2019 form. > I'd say that this is a feature, not a bug. I tend to agree. There are no examples I can produce of the U+0027 form being marked as invalid while the U+2019 form is marked as valid.
(In reply to comment #16) > In > spelling-correction terms (final manuscript copy) I can understand the > desire to change all U+0027 to U+2019, but I am not sure the entire way the > dictionary sub-system works needs to be altered to cater for *storing* the > U+2019 form. I'm not sure I understand, sorry (not a native speaker). Are you saying the storing of the U+2019 form needs to be altered? In other words, what is keeping this bug open? :)
(In reply to comment #17) > Are you saying the storing of the U+2019 form needs to be altered? No. But I am guessing that the original reporter was suggesting something similar. Currently the dictionary files only store U+0027 forms. This report seems to be suggesting that when a U+2019 form word is added (via spell-check to the user-defined dictionary) that the U+2019 form should be written to the file, rather than the U+0027 form as currently. If this is the case then this bug needs to be altered to an enhancement as neither OOo or LO have ever done this. My last comment was made in relation to what the average user would want to see on-screen i.e., U+2019 rather than U+0027. This can be achieved via existing means. > In other words, what is keeping this bug open? :) I personally feel that this bug report can be RESOLVED as either WONTFIX (if it is made an enhancement) or NOTABUG (if left as a "normal" bug). As an enhancement it would involve substantially changing the way in which dictionary files are handled / stored for all words contain apostrophes. This would affect not only LO but any application accessing the system dictionary files on a GNU/Linux system. I do not feel this is a good idea. In my opinion it is not a bug but a feature (as you suggested in comment #15.) Apologies for any confusion.
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
Migrating Whiteboard tags to Keywords: (EasyHack SkillCpp TopicUI) [NinjaEdit]