Does anyone happen to know if there is a complete list of Windows 10 localized folders (like this one just for all folders)?
I am trying to create a custom explorer where the folder should be displayed in the user's native language.
I have already tried to get a complete list of localized folders using the ShellSpecialFolderConstants enumeration or the Environment.SpecialFolder enumeration.
but there are still a few missing (C:/Users for example).
SHGetFileInfo is unfortunately also out of the question, because otherwise the performance would suffer massively.
I have thought of simply designing a long selection statement for it in which all localized folders are stored.
And if there was already a table of equivalents, it would of course be very handy to know.
Thanks in advance!
Microsoft does not provide a list because you are not supposed to know, you are supposed to use the special/known folder API. This is to prevent people from hard-coding c:\Program files etc. In older versions of Windows the folders on disk were often localized. In Vista this changed and the real names are English now.
If you are building a custom Explorer then you should be dealing with IShellFolder/IShellItem and they can provide the display name.
If you are working at a lower level and ignoring the shell namespace you can call SHGetLocalizedName. This name can be applied to any folder, not just special folders.
If you for some reason only care about the special folders and not paths in general, IKnownFolder::GetFolderDefinition claims to return a structure that includes the localized name.
Related
I want to check if two strings are paths to the same file or folder.
I've seen two questions dealing with this:
C# Canonical file names
and
How can one get an absolute or normalized file path in .NET?
.
All answers on both are wrong.
On Windows C:\A.TXT is the same file as c:\a.txt. AFAIK on UNIX/LINUX it's not, and on MacOS it depends on the user. (The code might be used on .Net MAUI on different OSs.) And it might depend on the file system even within one OS. Non of the answers there address that. But over a decade has passed since those questions were asked, and that's a lot in computer-years.
So, does .Net (perhaps .Net 7.0) have something for this?
More info: I don't want to touch the file system such as by opening both files and checking whether both point to the same one. I just want to do a text comparison. And I don't care about "different" files pointing to the same file such as by symbolic links etc. so it's fine if the files are considered different by whatever the answer is, even though they point to the same actual file.
EDIT
Some of the paths will be stored, and I need to know that they point to the same file if the user changed from uppercase to lowercase (on Windows). I also need a durable way to check file systems and OSs. Something that will be updated if filesystems will change etc. Like for example NTFS case-sensitive NTFS folders which most commentators here seem not to know about. There might be other pitfalls as well.
Either a Canonical(path) or a AreSame(path1, path2) would be welcome.
Filenames are just text. Both Windows and MacOS are by default, case-insensitive but case-preserving file systems. MacOS allows one to format a drive with a case-sensitive filesystem; I can't remember whether or not NTFS has such an option.
In either event, to compare to strings in a case-insenstive manner, use string.Equals():
string fn1 = GetFirstFileName();
string fn2 = GetSecondFileName();
bool areSame = fn1.Equals(fn2, StringComparision.OrdinalIgnoreCase );
To put them in a collection, list a Dictionary<TKey,TValue> or a set, use the appropriate constructor and pass it the StringComparer.OrdinalIgnoreCase as its key comparer.
My app has been designed to be able to run on two different languages, english and czech. In order to accomplish this, I've created 2 resource files:
If an end-user would like to add another language, for example GlobalStrings.fr-FR.resx, is it possible to allow for this functionality without rebuilding the application?
If we look at the properties of these resource files:
I'm not understanding what embedded resource means. Does this mean that in order for the app to consume this file, the application must be rebuilt?
How do we create a resource file, that is open to be extended/changed by the end user, without having to rebuild the entire application
?
Regular .Net resources are compiled into assembly with particular name and loaded by matching that name. So if "end-user" is ok to translate strings in resx file and compile resources into assembly with particular name (like "MyResources.cs-cz.dll") you can do that with default .Net behavior without recompiling main code. See MSDN:Packing and Deploying resources and related links for more information.
Note that you don't need Visual Studio for it and can use csc command line compiler to embed resources on user's machine - so if your really want you can provide simple script that compiles corresponding resx locally. Note that editing XML (resx) as text is generally not possible by regular person due to required encoding of some characters - consider technical level of your "end-users" before going that route. Plain text version of source for resource may work in more cases.
Usually this is not the case - if end-user localization is requirement you would create some sort of custom resource string management by loading strings from plain text files or database that users can update locally.
Windows defines five folder types (general items, documents, pictures, music, and video). In Windows Explorer you can get/set the type by right-clicking on the folder and selecting Properties->Customize->Optimize this folder for. I'm looking for a way to get/set folder type in C#. I've searched for this, but I must not be using the correct terminology.
Can someone point me in the right direction?
Update: Thanks to all for the insights! Thought this would be simple - apparently NOT.
Very odd. I can select a folder with no desktop.ini. I can change the properties of that folder, select a folder type, click apply, see a desktop.ini is created, and see the folder view change accordingly. However, I can delete desktop.ini and the folder type persists. Through Explorer restart. Through Windows restart.
With regard to possible shadow copies, I can find no evidence to support this. Except for C:, system protection is turned off on all my drives. Using ShadowExplorer, I find no references to any desktop.ini files.
Puzzling...
I think you can either use a desktop ini file or the registry.
However, if you create a desktop.ini in a folder be sure to add the "System" attribute to that folder, otherwise the desktop.ini will be ignored.
attrib +s FolderName
(or with C# Code)
Link to MSDN http://msdn.microsoft.com/en-us/library/aa969337.aspx
Folder type is stored in desktop.ini file located in that folder (which has SYSTEM attribute and its not visible by default - you have to uncheck "Hide protected system files in Windows Explorer settings).
Example desktop.ini content from Windows 7 from folder set to "optimize for pictures" or whatever its called in english Windows.
[ViewState]
Mode=
Vid=
FolderType=Pictures
To change/read FolderType you can just change/read that file.
That file (desktop.ini) can contain more settings (like custom icon file/resource location). See desktop.ini in standard Documents or Desktop folder.
Edit/update according to comment:
Maybe that happends, because files with system attribute may have shadow copy and they will be restored after you delete them? I'm sure that there is no other place where this is stored.
Try to overwrite that file instead of deleting.
In Windows Registry there are only default settings applied when you create new folders.
Also I made some more digging, and found some information about WINAPI function that handles desktop.ini files "more properly".
See this:
Create Icons for Folders in Windows Explorer, Using C# by Evan Stone at codeproject.net
One more thing about customized folders without desktop.ini - I think this is impossible. Check that again and make sure, that you can see files with system attribute.
Edit 2:
Please take a look at SchlaWiener answer, he pointed at something important.
I downvoted his answer, but I was wrong, now I cant undo my vote.
Well, you want a direction, so.....
This is a link to a Microsoft document about the customization for folders...
How to modify your folder view settings or to customize a folder
In this article you will find a reference to a couple of Registry Subkeys and Keys.
Of course they are not the same in different Windows version (too easy)
WinXP, 2003
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell
HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam
Vista, Win7
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell
Looking at the mentioned registry Keys and at the complexity behind these keys I really suggest to leave this work to the OS itself.
EDIT I have been hit in my self esteem by some rude comments below, so I have decided to search for a bit more documentation on this DESKTOP.INI file that seems to be a better option to solve your problem. I have found this documentation that seems to be very exaustive (but again it also demonstrates how handling correctly this little file is very complex) And by the way I have still to understand if just changing this file really makes a difference or not. As far as I have tried the test folder remains unchanged but this could be caused by some sort of caching.
im working on a project where in i need to populate some files from the server and show them in a webrowser to the user. Where user would be allowed to do basic CRUD operation on the file
The problem is that i cannot assign the name of the file/folder as unique id which i need in case a user deletes/renames a file i should be able to identify the file later.
My question is that is there anything unique about any file/folder in NTFS that is unique about them and that can be used? and how that information can be accessed using .NET c#.
Came across the BY_HANDLE_FILE_INFORMATION structure but it probably needs me to pinvoke.
UPDATE 1 - tried looking at the feasibility to use nFileIndexHigh and nFileIndexLow but they would need me to do a pinvoke and also this method cannot be used with folders
one link when they mention folders Unique Folder Identifier tells me that it isnt possible.
Disregarding the fact that it seems that you don't want to P/Invoke a different approach could be to use the Windows Shell API. This API has the concept of a PIDL which identifies a folder (or "similar" item) in the shell namespace. A PIDL does not change even if the user renames the folder. The drawback is that the Shell API exposes what you see in Windows Explorer, e.g. Desktop is at the root of the hierarchy even though it physically is subfolder somewhere on a disk.
I think the FILE_INTERNAL_INFORMATION structure, used to query for the file system's 8-byte file reference number for a file, is what you need. The IndexNumber is a number that uniquely identifies a file. You should use P/invoke to query this information.
Greetings all,
I'm trying to localize a .NET/C# project. I'm using string resource files and setting the "Localizable" property on all my forms to 'True'. The assembly culture is empty. The resx/resource files are successfully passed through Lingobit, resgen, and al.
When running the localized executables, some of my forms are not localized (ones in which I know the Localizable flag is set) while others are. There are even a few forms which are localized but a button or two isn't. I cannot tell any difference between the non-localized forms/controls with the localized ones.
Anyone have an idea what I might be missing? Thanks!
When you open the form in Visual Studio, if you change the Language property of the Form to the language you are localizing to, does the same problem exist there? Could it be possible that the non-localized forms/buttons still have the English text set even in the localized resources?
Yeah, I'd go with Andy on this and be suspicious of the contents of the resource files. We dabbled with localisation for a time, and encountered a number of issues, but this certainly wasn't one of them.
If that isn't it, then how are you testing your app? If you haven't tried this already I'd suggest firing up a set of VMs with foreign language versions of Windows installed (rather than just changing the language settings on your machine) and seeing if that makes any difference.
Okay, I figured it out. You guys were correct. We were not generating the translated resx files correctly from Lingobit. Some of the files would get translated while others had the English text still in the resx.
Thanks for your help!
EDIT: Just to expand upon this, we specifically were messing up the al.exe command which takes the binary .resources file and creates a satellite assembly adding it to the executable's manifest. In the /embed command, you have to bind the resources file to a namespace. Our top-level name spaces were mapped correctly, but we weren't binding to sub-level namespaces on all of the resource files.