Summary: | autocorrect entries in the [All] list are saved as English(USA) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | tommy27 <barta> |
Component: | Linguistic | Assignee: | Eike Rathke <erack> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | medium | CC: | courrier.oou.fr.mjk, erack, michael.meeks |
Version: | 4.0.0.0.beta1 | Keywords: | regression |
Hardware: | x86 (IA32) | ||
OS: | Windows (All) | ||
Whiteboard: | target:4.1.0 target:4.0.0.0.beta0 | ||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 54157 | ||
Attachments: | test "acor_.dat" |
Description
tommy27
2012-12-09 20:14:24 UTC
the bug was not present on an older master release Version 3.7.0.0.alpha0+ (Build ID: 24761a6) just tested on WinXP 32bit. new autocorrect entries saved in the [All] list are correctly stored as "acor_.dat" and not as "acor_en-US.dat" I hope this information will help to exactly identify when the regression took place in the 3.7 --> 4.0 development So the problem creeps in in the range: git log 24761a6..7061f72159e38e76134bc7fefc8a75cd233889c | grep Author | wc -l five thousand commits or so :-) If I was guessing, I'd think: commit 378e437fbe313e87b7e56f8f0a1fc4009470679c Author: Eike Rathke <erack@redhat.com> Date: Fri Nov 16 23:22:11 2012 +0100 use LanguageTag Change-Id: If056193c803f70f8707373ed7ff7b1abbf953852 1 1 editeng/source/misc/svxacorr.cxx diff --git a/editeng/source/misc/svxacorr.cxx b/editeng/source/misc/svxacorr.cxx index 3f2298a..d8ae94c 100644 --- a/editeng/source/misc/svxacorr.cxx +++ b/editeng/source/misc/svxacorr.cxx @@ -1905,7 +1905,7 @@ sal_Bool SvxAutoCorrect::FindInCplSttExceptList(LanguageType eLang, String SvxAutoCorrect::GetAutoCorrFileName( LanguageType eLang, sal_Bool bNewFile, sal_Bool bTst ) const { - String sRet, sExt( MsLangId::convertLanguageToIsoString( eLang ) ); + String sRet, sExt( LanguageTag( eLang ).getBcp47() ); sExt.Insert('_', 0); sExt.AppendAscii( ".dat" ); if( bNewFile ) Might be related; is it possible that some corner-case LanguageType enumeration like LANGUAGE_DONTKNOW is getting mapped differently there: sal_Bool SvxAutoCorrect::AddCplSttException( const String& rNew, LanguageType eLang ) ... else if(CreateLanguageFile(LANGUAGE_DONTKNOW, sal_True)) pLists = pLangTable->find(LANGUAGE_DONTKNOW)->second; Is liblangtag using the default instead of empty-string perhaps ? As suspected; fixed in master and will pick to -4-0. Eike - it worries me that other places using DONTKNOW will also behave differently - are you aware of that ? Tommy - thanks so much for testing it nicely, reporting cleanly and narrowing down the commit range well. Good work. Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a61928d2f7512d573e598b23c7fd3cf341f97780 fdo#58060 - use empty-string for LANGUAGE_DONTKNOW ie. acorr_.dat The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=08a3a5ee5b64105bb1b690d5fa4da83bbe220337&g=libreoffice-4-0 fdo#58060 - use empty-string for LANGUAGE_DONTKNOW ie. acorr_.dat It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. Argh.. this is yet another (now the 4th) meaning of an empty locale or string, what a mess.. ok, adding this to the list. There are ~30 places I need to check. Cleanest would be to have a reserved for local use "All" language 'qaa' or "dontknow" 'qdk' for this purpose instead of an empty string. The user profile's acor_*.dat files are migrated from 3.x to 4.0, aren't they? Maybe this would be a chance to copy oldprofile/acor_.dat to newprofile/acor_qaa.dat or some such. @Eike if this may help you,if you copy the "acor.dat" file from 3.6.x user profile into into the bugged 4.0 user profile, it will somehow work... I mean, LibO 4 still reads old autocorrect entries from the "acor.dat" file but saves new into "acor_en-US.dat" and load this one if you open the replacement table. I agree that it would be smart to rename the "acor_.dat" into a more intuitive name such as "acor_all-ALL.dat" or anything else to avoid the empty string locale. > The user profile's acor_*.dat files are migrated from 3.x to 4.0,
> aren't they? Maybe this would be a chance to copy oldprofile/acor_.dat
> to newprofile/acor_qaa.dat or some such.
Sounds like a good idea to me ! :-) acor_all.dat or something would be great [ reflects the UI name I guess ]. Once the migration bit is done it'd be a trivial fix in the svxacorr - though I'm concerned by the report that we continued to load the data with the acor_.dat name - I'd have imagined that wouldn't work.
Actually there's the 'und' ISO 639 code for "undetermined" that would fit here.. so acor_und.dat
> though I'm concerned by the report that we
> continued to load the data with the acor_.dat name - I'd have imagined that
> wouldn't work.
Indeed, that's a surprise to me as well.. while at it I'll try to figure it out.
Fwiw, I could not reproduce that copying an existing acor_.dat (or renaming the newly for "[All]" created acor_en-US.dat to acor_.dat) would result in that file being read in. @Eike. I'll retest later this evening. maybe I was wrong. Created attachment 71455 [details]
test "acor_.dat"
@Eike
I still confirm what I reported before. test it yourself.
download the attached "acor_.dat" file which contains a single autocorrect entry (Tommu --> Tommy).
place it in the autocorr subfolder of LibO 4.0.
then open a blank Writer document and digit "Tommu" it will be corrected ad "Tommy"
if you open the autocorrect options menu and select the [All] list you won't see Tommu --> Tommy entry, instead you will see "english american" autocorrect entries.
obviously the test I performed was done on the daily build before Micheal's fix.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbd9177a3985910312d4f6a4b7c2068bbab50619&g=libreoffice-4-0 fdo#58060 use acor_und.dat and LANGUAGE_UNDETERMINED It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=623410669fa2d5da9a2ce4e3c4b81ce23605a6df fdo#58060 use acor_und.dat and LANGUAGE_UNDETERMINED The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. regarding "acor_und.dat" the most important things is that it should keep the same "autocorrect power" of the old "acor_.dat". I mean, autocorrect entries in "acor_.dat" are applied in any language you write... from Arabic to Zulu... since it was intended as a list of universal autocorrect the same should happen with the "acor_und.dat" It does, it's just the language tag and internal mapping from/to ID that changed, the logic is untouched. An existing acor_.dat is copied to acor_und.dat during user profile migration from 3 to 4. thanks Eike. I confirm "acor_und.dat" works fine in latest LOdev 4.0 daily build. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.