I have an WPF application that uses custom culture resources and is published to a server to be later installed, or updated, via ClickOnce (I believe).
The problem lies within the custom cultures, which the hosts don't have and the installation comes to a complete halt due to the missing culture.
Is there anyway to force the installation anyway (the application does have checks to register the missing cultures) or to add somehow these cultures information when publishing the application?
To give some context, I have the following resources files:
Resources.en-GB.resx
Resources.en-GB-informal.rex
The first resources file contains the basic translation of the application, and the second one contains roughly the same content but in an informal/friendly context. This extends to other cultures.
Related
This is not a question about standard localization - I know how to localize the app, use resources, Uid's and so on - this works perfectly.
The problem is that the app comes within a bundle, therefore when the user installs the app it covers only languages that are selected in device/phone settings. But I would like to provide an option in settings that would allow choosing a language regarding the settings. For this purpose, I can use ApplicationLanguages.PrimaryLanguageOverride, which works very nice when deployed via VS, but as I've mentioned - version from the store lacks resources, as not all are installed.
Does anybody know how to bypass this bundle behavior?
The problem is also that I'm using MAT (multilingual app toolkit) and my translation comes with xliff files. I've spent quite a lot of time to find a way to convert them to resw files, without success. Is there any way to do it (or I've to write my own converter)?
You need to use ResourceContext:
var context = new ResourceContext(); // deliberately not using getForCurrentView()
context.Languages = new string() {"fr-fr"};
ResourceMap resourceMap = ResourceManager.Current.MainResourceMap.GetSubtree("Resources");
String str = resourceMap.GetValue("string1", context).ValueAsString;
More info at:
'How to load string resources' and
'ResourceContext class'ResourceContext class'.
PS. I have app in store and there is no problem with changing language without reinstall so all resources must be there
Check out this: UWP: Resource file for languages is not deployed correctly you need to get rid of bundle in order for my code from above to work. Or you could check if chosen language is installed in OS and if not you could not allow user to choose it using:
Windows.System.UserProfile.GlobalizationPreferences.Languages
In ASP.NET, an application can be localized using resource files. Resource files hold different translations. For example, one might have an English resource file and a Spanish resource file. When resource files are used, an attribute can be applied to controls on a web page to automatically populate that control with values from a resource file. Alternatively, the values can be programmatically loaded from a resource file and assigned to a control's property.
ASP.NET uses a fallback mechanism for loading translations. It tries to find the resource file that is most similar to the current user's culture. If the current user's culture is Spanish, ASP.NET tries to load the appropriate resource from the Spanish resource file. If the Spanish resource is not available, it falls back to a default resource file. Because of this behavior, text for a Spanish user may be shown in the default language for two reasons:
No Spanish translation is available. (The translators haven't provided a translation for this item yet.)
The text is not localized. (This may be the result of plain text appearing in the page or the message being hard-coded somewhere.)
If text appears in the default language, I want to know whether it was because of reason 1 or because of reason 2.
For every missing translation, I could insert some kind of placeholder text in a resource file. However, this means that I am throwing away the fallback mechanism. Even worse, if placeholder text accidentally makes it through to production, it looks much worse than showing the default text.
Does anyone have any suggestions (or solutions) for determining which of these two conditions is the reason for default text appearing during manual testing?
If I understood you correctly you want to verify that every localizable text is indeed in fact localizable and not burned in the code. To do this you should not be using a real culture (Spanish), instead you should create resources for a fake unsupported culture and provide an automatic translation for every localizable resource entry available in the default resources.
For example, if you have a default resource containing:
Entry1: This is a test!
you should create a resource in your fake culture containing:
Entry1: Th1s 1s # t€st!
You could even (and should) perform the creation of the fake resources automatically using a simple character mapping. This way, when you set the application to use your custom fake culture you know that every entry has a translation so you can find harcoded text. This strategy is used by Windows and is known as pseudo-locales. The use of pseudo translated strings makes it possible do development using the fake culture because the text is still readable and this improves your probability of finding hardcoded text.
Windows supports pseudo-locales since Windows Vista and Windows 2008 R2, so if your build and testing environment uses these operating systems you can associate your fake culture to one of these pseudo locales (for example qps-ploc). If you have unsupported operating systems just associate your fake resources to a real culture that you probably will never be supporting or just create your own culture.
Also note that even in a supported operating system, Visual Studio will not create satellite assemblies for these pseudo-locales unless you enable them on the registry.
I'm building a digital signage application and I want to deploy it using ClickOnce. (I feel this is the best approach.) When I start the application from Visual Studio (VS) it works great. The application downloads a lot of images from my web service and saves them to disk:
string saveDir = new FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName;
When I start my deployed application, it shows the splash screen and then disappears. The process keeps running, but the UI doesn't display. I'm wondering if my saveDir as shown above is giving me trouble?
How do I locate my installed application? (I need to make license files, etc.)
I'm not sure if this is the root of your problem, but I highly recommend you change the structure of how you store your application information.
When an application is installed through ClickOnce, the application is installed within the User's folder, and it's considerably obfuscated. Furthermore, locations may change with subsequent application updates, so you can not be guarantee than any cached, downloaded file will exist from update to update.
To solve this problem, ClickOnce does provide a Data directory, that is not obfuscated and can be used for caching local data. The only caveat is this directory is not available for non-ClickOnce instances of your application (like the version that is running within the VS debugger.)
To get around this, you should write a function that you can use to get your data directory, regardless of your method of distribution or execution. The following code is a sample of what the function should look like:
//This reference is necessary if you want to discover information regarding
// the current instance of a deployed application.
using System.Deployment.Application;
//Method to obtain your applications data directory
public static string GetAppDataDirectory()
{
//The static, IsNetworkDeployed property let's you know if
// an application has been deployed via ClickOnce.
if (ApplicationDeployment.IsNetworkDeployed)
//In case of a ClickOnce install, return the deployed apps data directory
// (This is located within the User's folder, but differs between
// versions of Windows.)
return ApplicationDeployment.CurrentDeployment.DataDirectory;
//Otherwise, return another location. (Application.StartupPath works well with debugging.)
else return Application.StartupPath;
}
Windows 7 uses an automatic mechanism to detect whether an application needs elevated administrator privileges. Or the application itself has a manifest.
Is there a way to find out programmatically whether a specified application needs elevated administrator privileges or not?
I don't want to start it to find it out.
Thank you ;).
There's really just one way to tell Windows that a program needs to be elevated and that's through the manifest file. Manifest files can either be embedded within an assembly (exe/dll) or can live in a separate file named <YOUR_APP>.exe.manifest. That's really the only way and probably the only way that you can safely check. Officially.
Windows also contains a giant database that's used for application compatibility. If Microsoft has tested an app and found that it breaks when an OS upgrade happens they sometimes creates an entry in the database to essentially hack the app. Sometimes they lie about the current OS version, sometimes they automatically run as administrator, sometimes they do a bunch of other things. You can view the database using the Application Compatibility Toolkit. I don't know if there's an official way to query the database via code. This blog post talks about a tool that the blogger made but apparently never release.
The last automatic elevation mechanism is algorithm that tries to determine if that app is an installer. According to MSDN these attributes are checked:
Filename includes keywords like "install," "setup," "update," etc.
Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename,
Internal Name, and Export Name.
Keywords in the side-by-side manifest embedded in the executable.
Keywords in specific StringTable entries linked in the executable.
Key attributes in the RC data linked in the executable.
Targeted sequences of bytes within the executable.
The keywords and sequences of bytes were derived from common
characteristics observed from various installer technologies.
Lastly, an app can run as a normal user but spawn a child process that requires elevated privileges. I don't know if there's really any way to actually detect that short of decompiling the app itself.
I have a winform EXE running using .NET 2.0 framework, when i sent this EXE to my friend who is using a machine where ALL the settings/OS(windows) are displayed in mandarin language.
When i try to open the EXE, i straight away get exceptions in mandarin language.
Is there something i need to change if i need to run an winforms .net EXE in mandarin machines?
Thanks.
There are going to be a whole host of localization issues. My own software has only been used with European scripts, but I still have to handle different number and date formats. So even simple things like reading and writing numbers from the registry (for default settings) require localization support. .NET 2 provides localization support - use the CultureInfo class to determine which formatting method/etc is causing the problem.
You will also need to do everything in Unicode (which you probably already know).
Running your program in a debugger should give insights as to what exactly is failing.