Apache OpenOffice (AOO) Bugzilla – Issue 117782
[IT] Not enough space for option description in Calc
Last modified: 2013-06-30 21:40:14 UTC
Created attachment 76329 [details] image describing error in italian ui In the italian version of OOo Calc there is a truncated description that needs a little more space to show correctly. Choose Strumenti - Opzioni... , OpenOffice.org Calc then Calcola. The option description "Limita decimali del formato di numero standard" is truncated. In particular, when selected you can see the selection highlight that is longer than the viewable words. The attached image speaks by itself. I also add that the problem seems not to show on WinXP, but is confirmed in WinVista, KDE and Gnome.
getting rid of value "enhancement" for field "severity". For enhancement the field "issue type" shall be used.
String still broken in 3.4.0. Assigning to Paolo so this can be fixed in Pootle in time for 3.4.1.
Andrea, this is not a translation problem, as you can see in the attached image there is room for expanding the viewable label. I am also unable to think of a shorter sentence for the same concept.
Reassigning to Juergen (to be further reassigned as appropriate) since this is indeed a generic localization problem: the space assigned to the string is too small for Italian and, very likely, for other languages, and it can be safely extended as shown in the screenshot. The original string is: Tools - Options - Calc - Calculate - "Limit decimals for general number format".
"jsc" committed SVN revision 1359176: "#117782# increase size of control"
fixed on trunk by increasing the size of the control. Until we have a really working layout mechanism the manual tweaking of the size is the only solution we have right now.
Checked with 3.4.1 (Rev. 1372282) on KDE 4.8.4, the problem is still visible.
This is fixed on trunk. Version 3.4.1 was released from the 3.4.0 code line with only a few selected fixes. The latest 3.5.x builds at http://ci.apache.org/projects/openoffice/install/ should contain the fix, but this is hard to verify since buildbots only build the English version.
Actually this doesn't seem fixed in 350m1 (AOO350m1(Build:9611) - Rev. 1400866). I'll shortly attach a r1400866 screenshot obtained by pressing TAB to highlight the field borders. Maybe the patch in http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sc/source/ui/src/optdlg.src?r1=1359176&r2=1359175&pathrev=1359176 is not enough?
Created attachment 80349 [details] r1400866 screenshot, not solved
(In reply to comment #9) > Maybe the patch in > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sc/source/ui/src/ > optdlg.src?r1=1359176&r2=1359175&pathrev=1359176 is not enough? The patch changed the size of the checkbox, but the next control, the fixed text didn't change, and is overlapping the checkbox There are two solutions: a) place the fixed text and the numeric field in a new row bellow the checkbox (there is enough room to do this) b) re-size and re-position the three controls in the same row, dynamically, according to the size of the fixed text
Created attachment 80351 [details] Fixed text and numeric field in a new row below the checkbox
Created attachment 80352 [details] Dynamic layout The controls are re-sized according to the optimal size of the fixed text.
Created attachment 80353 [details] Patch - controls in new row
Created attachment 80354 [details] Patch - controls in same row
Both options are sub-optimal, but that's all we can do with the current hard-coded layout. Pick one between attachment 80351 [details] and attachment 80352 [details]
mmh, seems to be a lazy fix from em, sorry. I am sure it worked on Mac and I thought it would be enough. I would prefer the fix in the same row. A working layout mechanism for VCL would be perfect but it's probably more a for now.
"arielch" committed SVN revision 1449742 into trunk: i117782 - Re-size controls according to the optimal size
Fixed on trunk
Thank you Ariel! We'll make sure to verify this with the next snapshot available in Italian (and, by the way, this affected other languages too, so it's good to fix it like you and Juergen did).
This is fixed in the latest 4.0-dev snapshot based on r1496831. Closing.