If you want to type Ω in the formula editor of a french version of LibreOffice, you have to type: %OMÉGA. It is inconvenient for two reasons:
- it is inconvenient to type a serie of uppercase characters.
- there is no key on french keyboards for É so you have to use the symbol catalogue with the mouse.
Two proposed solutions:
- %Oméga would suffice to specify the upper case greek letter. Just use the upper case for the first character (as done in Lyx).
- add an option to use the english codes in the formula editor (no localization)
Shouldn't be so hard to poke at this (I hope).
Code for parsing this seems to be in starmath/source/parse.cxx it seems the configuration XML has things like:
officecfg/registry/data/org/openoffice/Office/Math.xcu: <node oor:name="omega" oor:op="replace">
officecfg/registry/data/org/openoffice/Office/Math.xcu: <node oor:name="OMEGA" oor:op="replace">
Which I guess is where we get the unicode char number from. The unit test here:
starmath/qa/cppunit/test_nodetotextvisitors.cxx: parseandparseagain("%OMEGA", "Capital omega");
May be useful.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Removing comma from whiteboard (please use a space to delimit values in this field)
So I know exactly how to make the changes required for this bug to be fixed. As Michael Meeks pointed out it's in the
However changing this also requires you also change all the behaviors for the other symbols as it does not make sense to just have Omega be a special case. On top of that I'm not sure if the change should only be isolated to the french version or if I should go and make changes for every language set.
So I'm not entirely sure how to proceed. Should I just make the changes and just have this %Omega for capital and %omega for lower behavior just be for the french version or should I go a head and prepare to make changes to all language sets that we have?
If Grimm isn't working on this could I have a go at it ?
Should the changes made be in accordance with what has been mentioned in comment 4?
I prefer the second solution proposed by Frédéric for the following reasons:
- it's a very old problem and many users are accustomed to use localized names of greek letters; if we change the names used in French they will be confused.
- it is a more generic solution, valid for all languages
In fact, there is two difficulties here:
1/ the difficulty to type a series of uppercase characters; all users are concerned here, not only French users. The first solution proposed by Frédéric seems to me the best compromise.
2/ the difficulty to type an accentuated uppercase character; here only MS-Windows users for languages with accentuated characters are concerned. Indeed it is not a problem to type accentuated characters under Linux (at least in French). Here the second solution seems to me the right one. It solve another problem which is that many users do not know which accent they must type for greek letters in French. We already have the same kind of option for the function names in Calc.
Best regards. JBF
So its better I make the changes for all fully capitalized greek letters in the LibreOffice core rather than just for the french extension right ? Also, should the user should get say, Ω when they type both %OMEGA and %Omega ?
Patch by Darshana: https://gerrit.libreoffice.org/#/c/8696/
As Christian stated in the gerrit patchset, this is a localization problem.
At the moment starmath behaves like the following:
1. Inside the odf file the symbol names are in English.
2. If you have a localized version of LibreOffice (e.g. German), all symbol names are mapped to German for the UI. You see them in German, and have to write them in German.
3. If you store your formulas inside a odf file the localized symbol names are mapped back to the English names.
Ergo: Changing the tranlated %OMÉGA to a better representation in french should be no problem.
For the feature of supporting English symbol names in general, see Bug 32415.
Copy from gerrit:
%OMEGA is the capital omega %omega is the lower case character
Allowing a mixed version %Omega will make the formulas harder to read, especially with short ones like %Mu, %MU, %mu...
So I'm against mixed capitalization.
A cleaner solution for capital symbols would be %CaptialMu for example.
Here's the symbol code definition: starmath/source/symbol.src
StringArray RID_EXPORT_SYMBOL_NAMES holds the export names for the odf file (do not change!)
StringArray RID_UI_SYMBOL_NAMES holds the localized symbol names, which are language dependent.
Maybe we should approve some (less) user confusion and remove the translation of those Greek symbol names. None of the other function, operators,... are translated! Absolutely none!
To reduce the user confusion we could add the Greek symbols to the Elements Dock, so that they are easy accessible (see f5e2d31331839fd8c6039bec057a9c28ed3c7396).
What's the opinion about that?
I agree to remove translation of Greek letters: in French it is often confusing about how to write letters, for instance %rhô instead of %rho. But as mentioned in bug 32415, it would be better to use UNICODE letters (easy access through panel Element Dock) than letters of special font.
I do not agree with mixed capitalization: it would be too confusing.
I think the best (forward and backwards compatible) solution to this is to embrace unicode characters for Greek symbols and always write those instead of symbol names. We already use unicode characters when we import from MathML and doc / docx instead of symbol names (obviously because we don't know how to map between them).
To make this complete we need auto-replace so we can directly convert the symbol name into the unicode character (along with other user-defined symbols in the catalog).
I already did some experiments with unicode Greek symbols in Elements Dock (write the unicode symbol which is locale independent instead of symbol name) but they are useless if we don't embrace them everywhere. This is something I wanted to work on in the future..
%OMEGA and %omega are the best (in french) beacause theire is no É, als in english.
When we have a english version, we can works if it's all the same name.
If we decide to remove the translations, one questions comes up for me:
Looking at the current translation list inside the translations repo (e.g. for omega):
git grep -A1 'msgid "omega"' -- 'source/*/starmath/*'
It's not quite often translated. But, there are many Russian and Asian languages.
Are they able to input Latin characters as easy as with an qwerty keyboard?
There are usually no non-latin characters in formulas, so it wouldn't be much of a problem.
I don't have a French LibO version to test.
however I see that in LO 184.108.40.206 (italian version) and 220.127.116.11alpha (english version) the %OMEGA works fine if I want to type Ω.
please French users, give an update of this bug status with recent LO versions.
if bug is still there, please move if to mab4.3 list (Bug 75025) since 4.2.x is END OF LIFE
This bug is still present on a french version of LO 18.104.22.168 (tested on debian 7).
Setting priority to highest as this is a 4.3 MAB. This is part of an effort to
make the importance of MAB reflected in priority too.
Unclear why this is marked as a MAB (originally mab4.2, then moved to mab4.3). Now removing from mab4.3
Priority -> medium
Please leave a note if there's a compelling reason why this should actually be a MAB.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp, topicCleanup)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
A polite ping, still working on this issue?
Unassign due to lack of work.
If you start working on the issue again, feel free to assign yourself again.
I would like to work on this issues. It's my first contribution in LO.
First of all, I read all the comments and I still don't know what is the final decision. If you could guide me on what the product is suppose to do at the end of my contribution, I would appreciate.
(In reply to Marc Antoine Dumont from comment #27)
> I would like to work on this issues. It's my first contribution in LO.
> First of all, I read all the comments and I still don't know what is the
> final decision. If you could guide me on what the product is suppose to do
> at the end of my contribution, I would appreciate.
Second, is it still a real issues?
Closing this is a localization issue (see comment from Cloph), and thus we should not change the code and make incompatibilities.
Ok then I'm gonna look for an other issues.
(In reply to Marc Antoine Dumont from comment #31)
> Ok then I'm gonna look for an other issues.
Let me know if you need help.