What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

Björn — Thu, 18 Jan 2007 13:11:05 GMT

So, it might be due to the current state of caffeination of myself, but what is the solution for the mix path case? And is his non-localized element the user name in the path? And if, so, what is the solution to get "Bilder"? Will it be presented in an upcoming post? Will I continue to end sentence in this comment with U+003F a.k.a. QUESTION MARK? No, I guess I will not :)

Sidenote: Wouldn't it be easier and more readable to use C++ (or C++/CLI) for such samples - the interop declarations add a lot of clutter; maybe syntax highlighting could mitigate it...

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Thu, 18 Jan 2007 15:35:52 GMT

Actually Björn, that is not at all known or obvious, at the moment. :-)

I think it was mainly the fact that I was pretty tight for time that led to the language choice for the sample, though for this case losing the pinvoke declarations actually would have (in my opinion) required me talking more about the functions I was calling that were unfamiliar and their params....

re: What the %$#& is up with localized paths in Vista?

Dean Harding — Fri, 19 Jan 2007 03:53:46 GMT

Hmm, I'm not really sure about this "feature" actually. (That is, having the C:\Users folder untranslated for everybody, and only "displaying" a translated version)

I mean, I understand that for MUI and all that, you've got to have SOME physical folder name which may be different to what the user expects, but couldn't that name have been the localized version of "Users" (or whatever) when the OS was being installed (so if I installed in a French language, I'd get a physical folder name of "C:\Utilisateurs").

You'd still use SHGetLocalizedName to get the real localized name, but since 99% of people would be USING Vista in the same language that they INSTALLED it, most of the time it'd be exactly the same as the physical name.

As it is now, anywhere I want to display a path, I HAVE to use SHGetLocalizedName (a Vista-only function, of course), otherwise non-English users are going to be rather confused... Isn't it better to be wrong for 1% of users than it is to be wrong for 50% of users (whatever the proportion of non-English-speaking people use Windows)?

</end-rant> Ah well, I guess the boat as sailed on this one!

re: What the %$#& is up with localized paths in Vista?

Pavanaja U B — Fri, 19 Jan 2007 08:39:15 GMT

I have larger issue. Indic does not work on the console :(

-Pavanaja

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Fri, 19 Jan 2007 09:59:45 GMT

You have to try the new console for that!

re: What the %$#& is up with localized paths in Vista?

ph_arnaud — Fri, 19 Jan 2007 18:48:49 GMT

Thanks for getting some research and discussion going on this topic.

I also discovered that the function does seem to work for short paths and with trailing backslash.

c:\Program Files\ works. (implemented in a tiny MFC dialog app)

I am still interested to hear the solution for longer paths, as the average case may be to put in a titlebar a full path to a file, or a message box confirming save/delete/etc, with full long path name - with as you mention a mix of folders with no localized name available and a few folders with localized names.

For example:

C:\Users\admin\Pictures\bike.jpg

Just in case I tried to pass in some paths like:

Pictures

%USERPROFILE%\Pictures

with and without a real filename that exists in that directory, didn't get any productive result.

This function SHGetLocalizedName seems like it can't work for a full long path, because it in fact returns a 'path' (dll name, and res id) to find one localized directory name.

I believe pretty much the same issue existed on the multilingual version of Windows XP (enu with language packs), when switched to a language pack, (Explorer would show some folder names localized, vs true English names in the file system). But maybe no one really noticed as the ratio of 'full-localized' XP to enu + language pack XP was vastly skewed to full-localized XP as that was the consumer version available to most end-users.

Looking forward to more info on this topic.

re: What the %$#& is up with localized paths in Vista?

Pavanaja UB — Sat, 20 Jan 2007 06:18:34 GMT

> You have to try the new console for that!

Where is that?

Rgds,

Pavanaja

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Sat, 20 Jan 2007 08:48:45 GMT

It's called PowerShell? You have probably heard tell of it in other blogs; if not a search should be pretty easy....

(let's get this blog and its comment back on topic, kay?)

re: What the %$#& is up with localized paths in Vista?

James S. — Sun, 21 Jan 2007 00:14:20 GMT

The behaviour of the SHGetLocalizedName function seems correct to me (although the documentation for it is rubbish - the third parameter can't seem to decide whether it's in or out and the type is wrong). The string "C:\Users\Bloke" specifies a specific directory; that directory does not have a localised name. On the other hand, "C:\Users" specifies a different directory, which perhaps does.

Isn't the problem here that what we think we want is a function CreateLocalisedPath which maps each path component to its localised value? We could easily write one :)

Really though, the problem is that this functionality creates a one-way mapping from files to filenames, when most software and users expect bidirectional mappings (even if there are many of them). The user won't be able to type "C:\Utilisateurs", because it doesn't exist. It might even be a different directory! And of course, the vast majority of software won't bother with this particular tax, because the developers won't know about it.

Windows XP had this problem with the start menu. The default folders had desktop.ini files pointing to localised names. This was terribly confusing to anyone who tried to rename the items on the start menu, and doubly so if their user account's start menu folder lacked desktop.ini but the All Users folder did. "Fortunately", most users never organised their start menu, leading to the new search-based thingy in Vista (which I still consider to be a crime against the organised, but I'm hoping I'll get used to it).

Of course, junctions wouldn't help because there would need to be an infinite number of them :(

The real answer must be to use cryptic names like usr and bin to distract people from the issue :)

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Mon, 22 Jan 2007 10:38:20 GMT

For me the big problem is that this function (while probably useful in the context in which the Shell calls it) is mostly useless for anyone outside of MS (and even for most people within MS). And there is no clear indication of the correct function to be calling here, so there is no hint on where to go from here?

re: What the %$#& is up with localized paths in Vista?

Centaur — Mon, 22 Jan 2007 12:23:08 GMT

Why was it decided that names should be localized? Is it based on the assumption that users will not be able to learn a few foreign words? Personally I find this assumption insulting.

The abstraction that this function creates is inherently leaky. Users will not be able to use these localized names in contexts where they expect to be able directory names. They will say, “Why is there a ‘buffalo’ caption on the elephant’s cage? Computers are *so* hard to use”. They will learn not to trust the shell.

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Mon, 22 Jan 2007 13:15:06 GMT

You mean the original decison long before MUI and back when the first localized versions of Windows were being created? When not every user wanted to be required to learn English words, and not everyone at Microsoft wanted to force them to do so?

This was a decision made more than ten versions ago, so it is hard to pin down exactly why, but it's a little late to chuck it all now, IMHO.

re: What the %$#& is up with localized paths in Vista?

c2j2 — Mon, 22 Jan 2007 13:27:21 GMT

BTW: With the new Vista abbreviated names (c:\Documents == c:\Documents and Settings\[user name]\My Documents), it will be more likely for users to enter the path directly in an edit control (falling on the nose) than to select the path using CommonDialog (using a "browse" button after the edit control).

That entry form (edit control with a "browse button") is pretty much standard.

Thus for experienced users, they will experience more trouble ;-)

Will there PLEASE be a thorough manual on how to handle these path mappings correctly, in BOTH directions?

Christian

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Mon, 22 Jan 2007 13:41:20 GMT

Hey c2j2, see this post for why the shorter names happened....

re: What the %$#& is up with localized paths in Vista?

c2j2 — Mon, 22 Jan 2007 15:34:04 GMT

Thanks, MichKa, actually that's where I have seen them first ;-) But my problem is that the paths are so short that some users will enter them in the path edit box faster as selecting them though a commdlg LoadFile().

So what happens if a user enters "c:\dokumente\x.txt" in the edit box to save a file in the "c:\Documents and Settings\[user name]\My Documents" folder, as the knows "c:\dokumente" exists (from explorer)?

"File open error" as the directory does not exist!

a) my program expects this, creates the directory as needed and writes the file - will it ever be found again (for sure not in c:\Documents and Settings\[user name]\My Documents, but also "c:\dokumente" will not be visible in Explorer, will it? Will there be two paths of the same name, one my new directory and the other pointing to the "old", long-named path?)

b) creating the directory fails -> It will confuse the user as the directory does exist for the user (he can see it in the Explorer)

Anyway, the damage is done, and I fear it will cause some support contacts itself... so for compatibility reasons (or whatever reason is given for the localized paths) a lot of developers actually need to make their applications vista-compatible! Duh!

So all us application developers need to find an easy way for filename conversions, for example SHConvertFSNameToUIName() and SHConvertUINameToFSName()).

Christian

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Mon, 22 Jan 2007 16:07:46 GMT

Hi Christian,

You are actually in your argument using two entirely unrelated issues to try to argue against the problems of the one bring discussed here. We have:

1) The top level, virtual "My Documents" which maps to the longer path -- a feature that has been around since at least Win2000 and has not led to a huge number of people creating phatom new directories. I doubt thast renasming it will change this.

2) The localized path issue beung discussed here.

I would argue that the design of a textbox you type into is a mistake and I ususlly disable the textbox and force them to go through the fileopen dialog. I would recommend that you do the same here, frankly, as this works round 90% of the issues that concern you? :-)

re: What the %$#& is up with localized paths in Vista?

c2j2 — Mon, 22 Jan 2007 17:13:23 GMT

Hi MichKa,

What you describe (or I assume you describe) is correct, that these folders have been around a long time. I cannot create a "my documents\x.txt" as the folder is so pure virtual, it does not reside in my "c:\" root ;-) Try 'echo Hallo ">my documents\x.txt"'. No user can expect these paths in an edit control that expects a filesystem path.

Once he enters a physical (or seemingly physical) path, that is, a path that he "sees" as a subdirectory on the harddisk, it's different.

I mean the shortcut folders you described in the other post. As they are virtual, localized, but on the harddisk's tree, I would expect consitency. I can create a file "x.txt" in "c:\dokumente" in the Explorer, but I cannot in the command shell ('echo Hallo MichKa >c:\dokumente\x.txt") and also not in an application that enables fast copy&paste of paths (which is used by prof\b\b\b\busers who shudder at the slowness and awquardness of having to click to open a dialog to enable them to insert a path thay could insert much faster directly).

I don't have a localized Vista here, only an US RC1, so I cannot test what will happen.

Christian

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Mon, 22 Jan 2007 17:18:23 GMT

Again Christian , this is 100% unrelated to the localized dirs issue, happens on English too, and has been around since win2000. Please take it to the shell blog as it is their design and has nothing to do with the localized directories.

re: What the %$#& is up with localized paths in Vista?

Installers? — Tue, 23 Jan 2007 00:54:33 GMT

Virtually every installer created thus far presents an 'install location' choice to end users, with an edit box and a Browse button.

Am I correct that this can (and will) happen?

1. User on a French machine installing some English shareware

2. Installer prompts for install location

3. It reads: C:\Program Files\Appname

4. User thinks that it's a non-internationalized installer (with accent, exclaming "stupid Americans!")

5. User changes the path to C:\Programmes\Appname

Now the user has both a C:\Program Files folder and a C:\Programmes folder? Does Vista smart enough to handle this? What happens when they enter C:\Programmes into the address bar? Which folder is loaded?

re: What the %$#& is up with localized paths in Vista?

ph_arnaud — Tue, 23 Jan 2007 13:42:39 GMT

Hi,

I don't think you need English shareware to see the difference. You could use French or English designed for XP software, or even designed for Vista...

The German Office 2007 installer doesn't show the installation path in the 'default' installation steps - there are no practically no options and the software is just installed.

Only when you choose 'custom', then it does show the English name 'Program Files' as part of path in an edit box (enabled for typing). There is a browse button next to the edit box, which shows a tree structure with localized directory names. Selecting the localized name, then ok, does not change the content of the edit box, which will still contain the English name 'Program Files'. In the Office 2007 installer if you do replace the 'Program Files' with 'Programme' in the install path edit box, it doesn't seem to be an issue, the files are still really installed to Program Files - probably because of the Programme folder junction that exists and redirects? - and of course in Windows Explorer it appears to exist in Programme, whether you put 'Program Files' or 'Programme' in that install edit box)

Beyond installation (which is one time, and perhaps not seen by all users), is run-time usage.

Word 2007 in some cases appears to avoid showing complete paths in UI. For example on the titlebar for the active document, or save confirmation dialogs, it seems to show just the filename - thus avoiding the issue. I don't have any insight if this is to avoid this English/localized foldername issue, or done for other reasons.

German Word 2007 is not completely able to avoid showing full paths. In some cases like hyperlink name and tooltips, the English directory names, when contained in a path, do display.

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Tue, 23 Jan 2007 13:52:58 GMT

And everything still works, then. Some confusion? Sure. But that is preferred to some stuff being broken....

Windows Vista junctions points, MUI and localized folder names

Carlos Quintero's blog — Mon, 12 Feb 2007 13:33:31 GMT

I spent quite a few hours yesterday dealing with an intriguing thing that hapenned two days ago while

re: What the %$#& is up with localized paths in Vista?

Phil Jollans — Tue, 13 Feb 2007 16:05:58 GMT

Michka, I think localized directory names were a bad idea from the word go. I think that they were introduced in Windows 95, so the design decision was probably about 13 years ago.

You say that it is too late to chuck it now. It seems to me that the basic idea has in fact been chucked. What remains is some cosmetics in the windows explorer.

Localizing the names of directories, which under the surface actually retain their original names, seems so obviously a be bad idea, that the best approach is probably to boycott it. Working with filenames is a basic operation in many applications and the best way to handle it consistently is work with the real filenames.

I cannot imagine the localized aliases being a success and I fully expect Microsoft to abandon them in the following version of Windows.

Phil

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Tue, 13 Feb 2007 17:13:37 GMT

The real question is whether more has to be done other than what has already been done -- why not keep the small amount of cosmetic work? :-)

re: What the %$#& is up with localized paths in Vista?

i.g. — Thu, 15 Feb 2007 12:01:23 GMT

So, how can we convert

C:\Users\admin\Pictures

into

C:\Betnutzer\admin\Bilder

The SHGetLocalizedName() function works only for the first part (i.e. converting C:\Users into C:\Benutzer is easy, just like shown in the example code)... but how can we get the rest?

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Thu, 15 Feb 2007 16:36:55 GMT

If I knew, I'd have posted it -- but thus far no one seems to know the answer....

re: What the %$#& is up with localized paths in Vista?

Ming Zhu — Wed, 21 Feb 2007 21:00:49 GMT

I am from the Windows Shell team. I have recently come across a customer question with the link to this blog. I can see many confusion here and I feel that I can share the discussion here.

Actually, SHGetLocalizedName API is NOT designed to work with folders. The MSDN document already mentioned that it is used to retrieve localized names for files. Use it on folders has in-consistent result - for some folders it will work but for some it does not.

The official way to get a localized name for a folder is through the IShellItem::GetDisplayName or IShellFolder::GetDisplayNameOf method, it works on both pre-Vista and Vista systems. And, it works for all shell folders as well, include those non-file-sytem folders such as "Control Panel".

Here's some code example:

//
// Get the display name of a folder in the shell namespace according to the pidl
//
HRESULT GetDisplayNameFromPidl(LPCITEMIDLIST pidl, __out_ecount(cchName) LPWSTR pszName, UINT cchName) {
   IShellFolder *psf = NULL;
   LPCITEMIDLIST pidlRelative = NULL;
   HRESULT hr = SHBindToParent(pidl, IID_PPV_ARGS(&psf), &pidlRelative);

   if (SUCCEEDED(hr)) {
       STRRET sr;

       hr = psf->GetDisplayNameOf(pidlRelative, SHGDN_NORMAL, &sr);
       if (SUCCEEDED(hr)) {
           hr = StrRetToBuf(&sr, pidl, pszName, cchName);
           if (FAILED(hr)) {
               Trace(Warning, "StrRetToBuf failed, hr = %08X", hr);
           }
       } else {
           Trace(Warning, "GetDisplayNameOf failed, hr = %08X", hr);
       }

       psf->Release();
   } else {
       Trace(Warning, "SHBindToParent failed, hr = %08X", hr);
   }

   return hr;
}

//
// Get the a string form of the PIDL by concatenate the display names of the folders in the PIDL
//
HRESULT GetPidlStringFromPidl(LPCITEMIDLIST pidl, __out_ecount(cchPidlString) LPWSTR pszPidlString, size_t cchPidlString) {
   HRESULT hr = S_OK;

   // First, get the display name of each level of the pidl, and combine them together.
   // Since we used ILRemoveLastID() recursively, the order is actually bottom to top.
   WCHAR szReversedString[MAX_PATH] = L"";
   LPITEMIDLIST pidlClone = ILClone(pidl);
   if (pidlClone) {
       while (SUCCEEDED(hr)) {
           WCHAR szOneLevel[MAX_PATH];

           hr = GetDisplayNameFromPidl(pidlClone, szOneLevel, ARRAYSIZE(szOneLevel));
           if (SUCCEEDED(hr)) {
               StringCchCat(szReversedString, ARRAYSIZE(szReversedString), L"\\");
               StringCchCat(szReversedString, ARRAYSIZE(szReversedString), szOneLevel);
               if (!ILRemoveLastID(pidlClone)) {
                   break;
               }
           }
       }

       ILFree(pidlClone);
   } else {
       hr = E_OUTOFMEMORY;
   }

   // Now, we are gonna reverse the path in szReverseName, to get a regular top to bottom path
   *pszPidlString = 0;
   PWSTR pszLast = szReversedString;
   while (pszLast) {
       pszLast = StrRChr(szReversedString, NULL, L'\\');
       if (pszLast) {
           *pszLast = 0;
           pszLast++;
           if (pszLast) {
               StringCchCat(pszPidlString, cchPidlString, L"\\");
               StringCchCat(pszPidlString, cchPidlString, pszLast);
           }
       }
   }

   return hr;
}

You can see the above code works with PIDLs - the shell equivelant of paths. You can get the PIDL from many APIs such as SHGetFolderLocation, ILCreateFromPath etc.

Hope this helps.

Here is what's up with localized paths in Vista (and in Windows!)

Sorting It All Out — Wed, 21 Feb 2007 23:37:49 GMT

Some of you may recall the confusion surrounding localized paths in Vista that I mentioned not too long

re: What the %$#& is up with localized paths in Vista?

ph_arnaud — Thu, 22 Feb 2007 01:40:33 GMT

Thanks for the precise example!

Now let's see if we can get some recommendations from the Vista User Experience Guidelines team.

This is worth a topic in there. Do we do this mapping only in 'shell explorer' types of interfaces, or should any path shown in a Windows application (list of paths in compression tools, paths in confirmation dialogs, installation paths, etc.) be mapped to a localized folder paths.

I think they've got a link on their page for feedback...

mailto:winui@microsoft.com?subject=Windows Vista User Experience Guidelines feedback

If you had gotten there first, you might have staked your claim too!

Sorting It All Out — Fri, 21 Sep 2007 10:06:50 GMT

I was reading Raymond Chen's blog post Find the Flowers vs. Minesweeper which is a pointer to David Vray's

re: What the %$#& is up with localized paths in Vista?

Pissed-off user — Mon, 15 Dec 2008 19:30:46 GMT

I don't care that you screwed up the system 13 years ago. What you're doing now is *WORSE*! I can't begin to describe how fucked-up my system has gotten after installing a few programs on it. Any differences in handing file names between shell, GUI and installers is just *WRONG*.

I want a refund!

re: What the %$#& is up with localized paths in Vista?

Michael S. Kaplan — Tue, 16 Dec 2008 03:28:47 GMT

Kind of hard to comment given the lack of actual information, such as:

1) Initial install language

2) Names of the programs that were installed

3) For each program installed in #2,

---a) The UI language at the time of install

---b) The path to which the program was installed

4) the exact way in which the system thereby became "fucked up", specifically what failed and how -- and of course why said failure is so truly awful that a refund is required

5) How and where you purchased Vista (since you are asking for a refund, how you paid seems relevant!)

What the %$#&amp; is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

Windows Vista junctions points, MUI and localized folder names

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

Here is what's up with localized paths in Vista (and in Windows!)

re: What the %$#& is up with localized paths in Vista?

If you had gotten there first, you might have staked your claim too!

re: What the %$#& is up with localized paths in Vista?

re: What the %$#& is up with localized paths in Vista?

What the %$#& is up with localized paths in Vista?