Archive

Posts Tagged ‘Localization’

Fix: make ownCloud installer display in English language

OwnCloud is an interesting solution for setting up a file sharing cloud for a group of people.

However,one issue I’ve found with its Windows desktop client’s current version (which looks clean of any viruses since I always check first) is that if your Windows 10 is configured with a preferred language that the desktop client’s installer doesn’t have localization support for, then it doesn’t show up in English as you’d expect, but in Czech or someother language that most of us don’t know how to read.

Screenshot (493)

So I tried running it’s MSI installer (ownCloud-2.6.1.13407.13049.msi) with –? parameter from the command-line and the /g languageCode parameter mentioned there looked promising, but trying /g en for English didn’t work. I guessed it needed some specific language code number (and not double-letter language code like en for English), since the help text was mentioning to see Windows Installer SDK for more help.

After a quick search I found an article that suggested passing the parameter Productlanguage=1033 to an msi installer on the command-line for it to ALWAYS show in English. And indeed it worked.

Screenshot (494)

To open a command window one can click the Search icon on the windows taskbar and type CMD then press ENTER.

Then they can drag-drop the .MSI file of ownCloud installer onto the black command-line window that opens up and type an extra space char and then Productlanguage=1033 before pressing ENTER to launch the ownCloud installer in English. After that they can close the command-line window at anytime.

Since many users may be uncomfortable with such instructions, one could provide an msiEnglish.bat file that just contains

%1 Productlanguage=1033

User could drag-drop the .msi they want onto that msiEnglish.bat file and it would run the msi installer being displayed in English language, irrespective of any preferred language settings at the Windows operating system.

Of course the best thing would be if ownCloud fixed their desktop client installer to fallback to the Engish language (set it as default) if it can’t find localization strings for the currently prefered language of the user. Have filed an issue at https://github.com/owncloud/client/issues/7825

HowTo: include MVC model property Display name in Required validation message

Just came across this validation error display in an MVC app I’ve recently started maintaining. The required input field validation seemed to not be localized, resulting in a mixed English and Greek (from the field’s Display name) message:

image

Looking at the MVC model I noticed they were using [Required] attributes for the userName and password properties, together with [Display(Name = "…")] for the displayed property title

public class LoginModel
  {
     [Required]
     [Display(Name = "Όνομα Χρήστη")]
     public string userName { get; set; }

     [Required]
     [DataType(DataType.Password)]
     [Display(Name = "Κωδικός")]
     public string password { get; set; }

     //…

That was changed to:

public class LoginModel
  {
     [Required(ErrorMessage = "Το {0} είναι απαραίτητο.")]
     [Display(Name = "Όνομα Χρήστη")]
     public string userName { get; set; }

     [Required(ErrorMessage = "Το {0} είναι απαραίτητο.")]
     [DataType(DataType.Password)]
     [Display(Name = "Κωδικός")]
     public string password { get; set; }

resulting in a fully localized validation error message with the respective property’s Display name auto-inserted in the validation ErrorMessage, thanks to the {0} used in the message string:

image

Note there’s also the lazy route like in this property:

[Display(Name = "Περίοδος Εγγύησης(Έτη):")]
[Required(ErrorMessage = "Απαραίτητο πεδίο")]
public int warrantyPeriod { get; set; }

where you just say something like “Required field” in the localized error message. This however will work only when you always show the error message next to the input field that fails to pass validation.

If you want to also show a validation summary say at the beginning and/or the end of the page (depending on where your submit button is), you’ll end up with an error summary that may just contain multiple entries of “Required field” text without any indication on what field it was (which would be practically useless that is).

Note that sometimes due to lack of space in a webpage (say if you have lots of input fields in a grid) you can only show say red “*” near input fields that have validation errors and explain them more in the tooltips and in an error summary control.

Even better you can use resource strings to avoid error message string duplication. That approach, though a bit more verbose as implemented in ASP.net means easier centralized maintenance and localization from a per locale/language resource file and less typos or slightly different error messages for the same thing. See example and related screenshots at https://stackoverflow.com/a/22849638

Difference between LocalizableAttribute and LocalizabilityAttribute in .NET

I’ve just updated an older answer of mine at:

https://social.msdn.microsoft.com/Forums/vstudio/en-US/716ef041-0a59-4c1d-9519-e14db4de7e75/localizability-vs-localizable-attributes-in-control-dev?forum=wpf

In case you’re wondering too what’s the difference between Localizable and Localizability attributes in .NET, maybe this helps a bit:

https://msdn.microsoft.com/en-us/library/ms753944(v=vs.100).aspx 

Seems the Localizability attribute is BAML-specific and makes sure localization-related comments (probably to make use by localization tools and show to the translators) are preserved/exposed when WPF XAML is compiled from text XML form into binary BAML.

HowTo: Set UI language (CurrentUICulture) in Silverlight

At LvS (the opensource application of LeViS), I’ve been using this (VB.net) code to set the UI language (for example to Greek):

Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo("el")

Others seem to have been using (C# – that’s why there is a trailing semicolon):

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("el");

assuming System.Globalization and System.Threading namespaces have been imported.

However, now that I’m building ClipFlair in Silverlight (http://clipflair.codeplex.com), I noticed both GetCultureInfo and CreateSpecificCulture aren’t exposed to Silverlight. Seems one needs for example to modify their App.xaml to use new CultureInfo("el") to do something like below (see parts in bold):

 

using System.Globalization;
using System.Threading;



private void Application_Startup(object sender, StartupEventArgs e)
{
CultureInfo c = new CultureInfo("el");            
Thread.CurrentThread.CurrentCulture = c;            
Thread.CurrentThread.CurrentUICulture = c;



this.RootVisual = new MainPage();        
}

 

Alternatively you can set at each XAML page/control the “language” attribute of the “UserControl” element.

If you want to enable dynamic on-the-fly localization based on end-user selection of UI language at runtime (say via a drop-down box), checkout a nice solution (the “Localizer” one) at:

http://stackoverflow.com/questions/3992007/how-to-switch-ui-culture-of-data-binding-on-the-fly-in-silverlight

%d bloggers like this: