Apache OpenOffice (AOO) Bugzilla – Issue 79937
Native filePicker not fully localized
Last modified: 2017-05-20 09:13:56 UTC
Testing on Mahos m221_de (German) version, I found the follwing items in FilePicker Window still in English: The name of the Window itself stays "Open" instead of "Datei öffnen" The kind of file to open stays "Enable" Teh buttons at the bottom stay "Open", "Cancel", "New Folder"
Uwe: is your UI language English or German?
German
I can verify this with UI language set to German. However I cannot even get my simple test programs to correctly display a German NavigationServices dialog using the usual bundle localization techniques. Doing the same with a simple Cocoa test app reveals no problems. But we will have to do change some bits and pieces anyway before the aqua version is fully localized bundle-wise.
confirmed with Intel based Mac. The buttons are not writen in German. I Use Aqua build m225 Pleas set Status to Confirmed Thanks
target
what about add .lproj dirs in the Bundle ( in Contents/Resources exactly ) ? Would solve a lot of localizqtion issues, and we could complete with the missing one ? e.g. : create French.lproj ( or maybe fr.lproj ) helps to localize all dialog boxes.
Nobody interested? Just wondering why reinvent the wheel when a solution does already exist for >95% of the use. Of course another solution could be used for the <5% remaining.
The question is just for what languages we should add the directories. For all languages supported by OOo? For all languages supported by MacOSX? But one problem I still see with this issue is that no matter which languages we decide to use, if we have e.g. a French OOo but the user runs it with the system language set to e.g. German, then the file picker and other native dialogs would be displayed in German while the rest of the app is in French. Haven't tried this though...
Move target.
To me, the correct "rule" for creating the .lproj directories is: Create those lproj -directories for languages that the OOo build supports. That way the language within OOo (OO user interface + filepicker) is same, when possible (i.e. Mac OS X localization exists for that language). There are ways users can still get funky combinations, but we don't need to care about the corner cases. No need to over-engineer the problem. The challenging situation is that when user installs new OOo lang packs, then those lang packs should add an appropriate .lproj dir too. Unless it exists already, of course. Do we support user-installable OOo lang packs for Mac, by the way?
This issue is targetted to OOo 3.0 but has not been set as a release-blocker. Please retarget it or close if fixed.
is this still a valid issue ? set target 3.1 anyhow.
OOo3RC2 (Sun build) works correctly on this. Is there an issue with langpacks left? Otherwise this one can be closed.
seems to be fixed
one less :-)