/build/static/layout/Breadcrumb_cap_w.png

Undocumented translation flag on NTFS directories

This may be a bit off-topic for the distribution board but since I came across this problem when rolling out multilingual installs and it does affect MSI installations which place shortcuts in new groups on the start menu I figured it might be interesting for others as well.

Background:

I have come across a rather interesting problem while attempting to create an English / Swedish multilingual environment in Windows XP Pro based on the Multilingual User Interface (MUI) pack for XP.

A new feature for the Windows XP MUI pack is that it translates even the start menu shortcuts. I am trying to mimic this behaviour by editing the 'desktop.ini' file which contains references to language strings contained in EXE or DLL files to dynamically translate filenames and directory names to the current GUI language of the logged in user.

For example, the 'desktop.ini' file in Start Menu\Programs\Games looks like this:

--- snip ---

[LocalizedFileNames]
Pinball.lnk=@%SystemRoot%\system32\shell32.dll,-22057
Freecell.lnk=@%SystemRoot%\system32\shell32.dll,-22030
...
more filename=translation strings
...
Internet Backgammon.lnk=@C:\PROGRA~1\MSNGAM~1\Windows\bckgres.dll,-1212

[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21773

--- snip ---

The first section maps filenames in the current directory to string values in the referenced DLL files. The second section does the same for the current directory.

This has the advantage that the path to the actual shortcut always stays the same no matter what user interface the user has chosen, while the name of the shortcut is translated into a localized version before being displayed to the user through the start menu or the Explorer.


Problem:

However, I discovered that no translation took place for newly created menu groups created under the start menu. I tried using the same 'desktop.ini' and the same shortcut names, all without result. After experimentation it turned out that you can only achieve directory and filename translation in certain directories, for example all the pre-created menu groups under the start menu.

The 'translation = enabled' flag is set per directory. It is possible to copy one of XP's pre-created menu groups to another directory on the local harddisk, clear it of all its contents, create a new desktop.ini file in it and new shortcuts and achieve translation on them.

Doing the same operation on a directory that I created myself had no effect on translation of neither the directory name nor any of the filenames in it.

I also tried mapping another XP workstation's local C: to a local drive letter. Copying a directory with the translation flag set to this remote drive preserved the translation flag and enabled translation of the directory and its files on the remote workstation. The translation also took place when viewing the remote directory from my local workstation over the mapped drive.

Performing the same operation with a Samba share as target stripped the copied directory of its translation flag and disabled further translation.

I have been unable to find any documentation on this issue. Indeed, I can't find any mention of this special flag in any of the API calls used to create or manipulate directories under Win32. An extra note is that xcopy does not preserve the translation flag. Explorer does preserve the flag and so does my test Python script which uses Win32 API calls for copying directories recursively.

Frankly, this has me a bit stumped. I can certainly make a workaround for the problem but it would be useful if an API call could be used to create these types of special directories.

Anyone with further information on this?

0 Comments   [ + ] Show comments

Answers (1)

Posted by: Jonas Olsson 19 years ago
Senior Yellow Belt
0
*sigh* Some days you shouldn't get out of bed. We thought we checked all available file attributes but somehow we managed to overlook the read-only flag that was set on all directories where translation worked.

A few lines of script later and I was able to verify that it was indeed the read-only flag on the directory that controls whether or not the directory and its contents are translated by desktop.ini entries.

The reason that xcopy didn't produce translating directories is of course that it doesn't preserve the read-only flags on directories. Neither does a Samba share.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ