Hi,

I've been working with CFBundle unit to try and figure how to get information about language settings, and so far with no luck. I've read about how Mac OS X works with internationalization, which automates language processing, but this is "no can do" for me, or I just can't get the right information.

All I need is to retrieve a kind of ID for a users language setting, in the same way as we would do in Win32 environment with Syslocale and PriLangID.

Any ideas of how to retrieve these kinds of information for Mac OS X?

I'm using FPC 2.2.0 and Lazarus 0.9.25 (15279) on i386/Darwin/Carbon.

Thanks,
Normann

I guess you mean that you read this: http://developer.apple.com/documentation/Porting/Conceptual/win32porting/Articles/intern.html ?

All I need is to retrieve a kind of ID for a users language setting, in the same way as we would do in Win32 environment with Syslocale and PriLangID.

It is usually a very bad idea to try to literally port APIs from one platform to another and disregarding platform conventions. It will make your program behave in unexpected ways for the users (e.g., many Mac OS X users expect to be able to ditch language support they don't care about X by simply getting info on your application bundle and deleting the language support from there).

It will also give FPC/Lazarus a bad name if many apps written in it look and behave like "Windows applications with an Aqua skin" (just like Java apps generally have a bad name as far as the user interface is concerned).

Jonas

Aside from Jonas' remarks, FPC 2.2.2 comes with a locale unit that loads the constants in sysutils with the system's locale settings when you include it. I verified, and it is also enabled for Darwin.

Note that it doesn't allow to load arbitary locale settings.

In addition to Jonas remarks, it is better to stick to generally used ISO locale designations rather than some arbitrary enumeration on Windows.

Those locale settings are unrelated to the current language selected in the system preferences on Mac OS X.

Jonas

Yup, I know, but it's a 1-1 port from Win32 to Mac, and it does have a little Carbon feel and look, but the application applies its own dynamic language structure based on a default language setting retrieved from PriLangID.

Thanks,
Normann

Bent Normann Olsen wrote

Yup, I know, but it's a 1-1 port from Win32 to Mac,

That's really a very bad idea, unless you are only interested in supporting Windows users switching to a Mac (although even for them the application will feel weird after a while).

http://www.google.com/search?hl=en&q=site%3Adeveloper.apple.com+obtain+user+language -> fourth link

-> http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Articles/ChoosingLocalizations.html#/ /apple_ref/doc/uid/20002397-DontLinkElementID_1 :

"There may be situations where you want to get the preferred locale ID or the list of languages directly from the user preferences. Mac OS X stores each user's list of preferred languages in that user's defaults database. The list of preferred languages is identified by the defaults key AppleLanguages and is stored in the global variable NSGlobalDomain. You can access that list using the NSUserDefaults class in Cocoa or the Core Foundation preferences functions."

-> CF preferences reading code: http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPreferences/Tasks/UsingHighAPI.html#/ /apple_ref/doc/uid/20001169-TPXREF106

->
CFArrayRef langArray =
(CFArrayRef)CFPreferencesCopyAppValue(CFSTR("AppleLanguages"), kCFPreferencesCurrentApplication );

Or in Pascal:

var
   longArray: CFArrayRef;
begin
langArray
:=CFArrayRef(CFPreferencesCopyAppValue(CFSTR('AppleLanguages'),
kCFPreferencesCurrentApplication))
end;

Then use CFArrayGetCount to get the number of elements in the array, CFArrayGetValueAtIndex to get the actual values (they are CFStrings). And keep in mind those are not canonical names (as mentioned in the last link, you may want to call
CFLocaleCreateCanonicalLanguageIdentifierFromString() to get the canonical name; although you'll have to import this function manually, as it does not yet exist in MacOSAll)

Jonas

Thanks Jonas, that did the trick ;-)

Preferable we will work on a more clean Mac OS X friendly release of our application on the next version, but to get the existing code working we need this.

Thanks,
Normann

So what do Mac users do with all these web-applications and "web 2.0" with their other GUI rules ? Start crying ?

Really...

Michael.

Op maandag 23-06-2008 om 18:00 uur [tijdzone +0200], schreef Michael Van Canneyt:

So what do Mac users do with all these web-applications and "web 2.0" with their other GUI rules ?

The same as windows and linux users...

Start crying ?

Indeed. :)

Joost.

2008/6/23 Michael Van Canneyt :

So what do Mac users do with all these web-applications and "web 2.0" with their other GUI rules ? Start crying ?

Best example yet! :-)
I really find these "native look and feel" debates pointless. Users are *not* that observant. And don't compare 'users' to 'developers'. As long as an application works and does what it was designed for, in a consistent way, you will probably make 90% of the users happy.

Your example of the web fits perfectly into my argument. All the different users experience the web in exactly the same way, no matter the platform. They all seem to survive the non-native look. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Is it really that hard to imagine that an application which uses the conventions of a different platform is unnecessarily hard and annoying to use? For example,
* if it uses different shortcut keys compared to all other applications (both for menus and/or for text editing)
* if it has various menu items in different menus than you'd expect
* if it puts all buttons in dialog windows in the opposite order and in different places compared to other applications so you intuitively click the wrong button half of the time
* if it does not honour your system settings and requires you to reenter a bunch of globally available information used by other applications again in its own preferences
* if it quits when you close its last window while virtually every other application stays open (apart from simple utility apps)
* if it puts up modal dialog boxes all the time which block the entire application instead of just the document the dialog box pertains to like other apps
* if it implements dialog boxes like a font chooser or colour picker in its own way rather than using the default system ones you are used to from all other apps
* if it insists on putting its shared libraries in global system/user locations so they can interfere with other apps
* if it insists on spreading files all over the system instead of grouping all these files in a single bundle so that an uninstall operation requires an uninstaller or manual fiddling rather than just "delete the bundle" like most other apps
* if it puts its preferences file in a non-standard location
* if it requires you to click "apply" buttons all the time in dialog windows while virtually no other application has them (except if the setting causes state changes which are not easily undoable)
* if it looks completely different from other applications so instead of basically ignoring the looks and just focussing on the functionality, your attention is diverted because it does not look like what you are used to
...

If you have the choice between such an application and one which looks and behaves as you've come to expect from other applications, what would you choose? It's not about what is better or worse (nor about Mac vs Windows vs Linux users), but simply about what you expect and are used to from other applications running on the same system. It's just as bad when trying to force Mac UI paradigms on Windows users (like Apple does with Quicktime Player and iTunes, although they have made them slightly more consistent with common Windows UI behaviour over time after harsh criticism on the initial releases).

Jonas

Well, I can imagine being a women, so: No, it's not hard.

But for a company that has 'Think different' as a motto the insistence on adherence to the rules is ironic :-)

Secondly, all things you mention apply to advanced users only, and I dare say to developers only:

I invite you to visit ALL our customers. Most of them don't even understand what a folder is. They *really* don't care about the rules you mention. Most of them would even be far more happy with a plain DOS application.

As our support staff says:
The best application has just 1 screen and 1 button: 'Click here', which, when clicked, scans the user's brain and does what (s)he wants. Some users will even manage to mess that up.

So: nice theory, but in practice: forget about it, it's not that important. We have other problems to worry about.

Michael.

2008/6/24 Michael Van Canneyt :

But for a company that has 'Think different' as a motto the insistence on adherence to the rules is ironic :-)

:-)

Exactly my point! Our support staff still has to explain to the users when to left click and when to right click. Some don't even know what the Desktop is, though they admit they have heard of it! All the things Jonas mentioned only relate to advanced users or programmers. They do *not* apply to our users.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Michael Van Canneyt wrote

But for a company that has 'Think different' as a motto the insistence on adherence to the rules is ironic :-)

Actually, it makes perfect sense since it's apparently so different from what you are used to that you consider it a completely outlandish concept.

Secondly, all things you mention apply to advanced users only,

Compared to your customers, most Mac users probably are "advanced". Most certainly not because they are smarter or better, but because the consistency makes it easier to become advanced (learned skills carry over much more easily from one application to another). Even my mother is probably "advanced" in this way, even though she also started out with simply memorising which icons to click in which order (she really is everything but a computer person).

and I dare say to developers only: I invite you to visit ALL our customers.

I invite you to ask on any number of "regular joe" Mac sites, forums or mailing lists how important the people there think that it is for a program to adhere to the standard user interface conventions (except for games, where total immersion into the game world is often more important, and simple widgets where you only have a text field and a button or so).

That said: if people are in front of your application five days out of seven from 9 to 5, it is indeed probably less important to be consistent with anything else. The learning curve may be fairly steep, but that doesn't matter since companies always provide training. Users may notice the different interface in the beginning but since they're so often in front of it, it will soon enough blend into the background. They'll also learn the layout and the automatisms required to operate the application after a while (no matter how contrived the interface may be: we even have administrative people at our university who have learned to be somewhat efficient with our SAP implementation, which is universally recognised by everyone here as a the most horrible user interface they have ever used).

This is however quite different from an application which isn't purchased by some PHB, but by a home user or independent professional (and traditionally that market has been much bigger than the corporate one in the Mac world). In that market, blending in and making your interface as little distinctive as possible is vital to be able to close the sale in most cases (at least in the Mac market).

Even in the corporate world actually paying attention to user interface consistencies could probably help the users a lot, but there it's seldom the users who can decide on what to use. And once they do get used to your particular interface, it's probably even a competitive advantage to have a lot of proprietary concepts since switching to a different application would require significant retraining.

Jonas

2008/6/24 Jonas Maebe :

That said: if people are in front of your application five days out of seven from 9 to 5, it is indeed probably less important to be consistent with anything else. The learning curve may be fairly steep, but that doesn't matter since companies always provide training. Users may notice the

You are raising a valid point about 'five days a week' infront of the same application. Which is our case.

Even so, I think there must be a distintion between 'different' interfaces and 'wayout' interfaces. For example, fpGUI has it's own Fontand File Open dialog. It looks different, but it works fundamentaly the same to Mac, Windows, KDE or Gnome dialogs.

File Dialog:
- You have some form of navigating through directories
- You somewhere have to select the file you are interrested in
- You have to click on the OK or Select button to choose the file and close the dialog.

Font Dialog:
- You have a listing of fonts (maybe even font families)
- You have a font size selection
- You have a set of font attribute/style choices
- You probably have a font preview area

The layout or look of the dialogs might be different, but fundamentaly they work identical. This is what I'm trying to get across. Any Mac or Windows user will be able to use the fpGUI dialogs without training!

About a month ago, I had a chance to play around on a Mac for a day. I have never used a Mac before. Other than the menus being in different places and programs not closing when you click the close corner button, the fundamentals workings of the applications and dialogs were the same to Windows or Linux (Gnome/KDE). You just need to *read* the screen!! OK, I'm not the average user, but I didn't need any special training to select a font or open a file.

Other than designing some 'Minority Report' user interface with virtual gloves etc, all desktop GUI applications work very similar. The rest is just eye candy.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

The layout or look of the dialogs might be different, but fundamentaly they work identical. This is what I'm trying to get across. Any Mac or Windows user will be able to use the fpGUI dialogs without training!

I don't doubt that for second. Just like in case someone would move around all the furniture in your house and hang all paintings in a different place, you'd still find your way around and all your stuff back. But you'd lose the advantage of all acquired automatisms. You'd probably hit your toes right after getting out of bed because before there was no table leg in that place. And for a while you'd probably focus on the wall every time you enter a particular room because it doesn't look like what you unconsciously expected it to be.

For some time you may even "see" (out of the corner of your eye when walking by) the old painting there unless you consciously had that when my bike was stolen: I didn't use it very often, but I passed it in the hallway every morning on my way to work. Several times at work I had a weird feeling and thought I should properly check my bike on the way home because there appeared to be something amiss. Only after 4 days I finally managed think of properly looking and saw that it was gone. The brain is really good at filling in details you expect to be there.

So it's not primarily about being unable to use something (except in really extreme cases, or possibly for people like my mother), but about diverting attention/time from performing some task to how to perform it.

You just need to *read* the screen!!

Exactly my point. The sooner you become oblivious to the interface and can let muscle memory (mostly) take over, the better. Your brain also doesn't really read the screen half the time, it just predicts what will be in which place based on past experience and if something different happens, you'll probably only realise it after performing the action. Just try changing one of your applications so that it occasionally switches the order of yes/no buttons in dialog boxes. Make sure you don't do it for the "Erase hard drive" one though :)

Jonas

Only superficially. If you take the statement to its logical conclusion, every application should be totally different from all other applications, otherwise you didn't think 'different' when you designed it.

That's just experience. My 11 year old daughter has no problems with the fact that we have Linux at home, even though they learn on Windows at school.

And this qualifies as 'advanced users'. The "regular joe" never ever visits a website about computer programs.

The audience on which you base your conclusions is not a representative sample, which - as any statistician will tell you, even psychologists know this :)
- makes any conclusion worthless.

Basically, any web-based poll is useless unless your target audience is the advanced web-user; A well-known fact for polling bureaus.

At most, you ccould conclude that the Mac users are a self-contained incrowd of 'advanced users'.

But once more: with the trend of web applications, I think they'll have no option but to blend in with the mere mortals that make up the rest of the computer user crowd. The observation that they will resent this, is like kicking in an open door...

All is relative, as a famous German scientist once said...

Michael.

This kind of reasoning is really very sad. Bluntly sad, it says: "Our users are stupid, so our software can be stupid too". Again, I find that very sad. I have been writing software for the Mac professionally for over twenty years, but never met a stupid Mac user. The level of experience may differ, but good software lets the user experience grow. It makes it a pleasure to use a computer, not a frustration.

From supporting multi-platform software for many many years I also know that the average Mac user is more demanding than the typical Windows user. Sometimes, you get away on Windows on with clumsy interface design or error messages (that's what they are used to anyway) but a Mac user will invariably complain about it to the helpdesk !

If you say "Most of them would even be far more happy with a plain DOS application" that's a pure disqualification of the software you offer.

Breaking the rules of the platform is never a good idea. As an example why, many Mac users still resent the user-interface of the Mac OS X Finder as compared to the old Mac OS Finder (which was better in many ways and still is).

So: nice theory, but in practice: forget about it, it's not that important. We have other problems to worry about.

I you do have other problems to worry about than platform consistency and interface design, that's again a disqualification of the software you offer. Platform consistency and interface design is where you start when writing software, it's not a gadget hacked into it afterwards.

Regards,

Adriaan van Os

Well,
the logical flaw in the statement aside, I suggest you contact Microsoft:

The support guys were referring to users using Microsoft software when they made this particular remark :-)

As for the software I develop: I believe in empowering the user, and go to great lengths to ensure this by a consistent design, powerful tools for the end user, so he can do the task at hand (he has many of them) in any way he sees fit.

A comparative study about usability, ergonomics and user-friendlyness
- done by an independent party - between my software package and the other existing packages gave us twice as much marks as the first runner-up, so I believe I succeeded in my goal.

We have also become the greatest player in the field, which goes a long way to back up this statement, if we can believe the rules said to govern the market.

Unfortunately, all this does not automagically improve the level of many of our users, which happens to be rather low (through historical circumstances beyond our control). But we try, nevertheless.

Michael.