by Michael S. Kaplan, published on 2010/05/17 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/05/17/10013731.aspx
So, where do I start?
Oh yes, I remember.
The .Net Framework's first and in the minds of some still respectable to be using right now UI technology, WinForms.
There is a particular feature they have, an AutoSize feature. When used (and used properly) it tremendously lightens the burden on localization since it will resize forms and controls to fit the text they contain.
Note the "used properly" notation there. This is important as I know of a project or two (or ten, or twenty!) that are part of a tiny little product you have never heard of called Windows that didn't really tend to do it right.
Which is not the end of the world. Not for you, or for me, or for the developers who created the forms, or for the localizers who had to do some resizing when text would truncate.
Everyone continued to function normally.
I guess the localizers had to work a little harder.
So no big deal right?
Oh wait, I forgot something.
Something about this AutoSize feature.
Now obviously a developer who was trying to use this feature might want to exert a little control over what it does, right?
I mean, letting people do stuff with no safety controls over how much they do leads to derivative market inspired economic collapse or unprecedented oil spills.
We know we don't want our WinForms to be all bankrupt and oily. So some ability to rein in the way that things might want to grow can make a little sense.
Of course the complexity of those ways to control the unprecedented growth is one of the big reasons why the AutoSize feature was so poorly utilized.
Why Windows became the son and heir to more than just a shyness that is criminally vulgar; it also inherited a whole bunch of oily, bankrupt WinForms applications.
The Smiths would be so disappointed.
But that is not the principal issue I wanted to discuss.
I really wanted to talk about the localization process, and then a couple of the properties that the original developers have to help rein in AutoSize if they believe they have a need to, and how all of that fits together.
The process, in a nutshell:
Well, there was a problem or two.
But for the moment I'll just talk about one or two of them.
Now one way that the developer can exert some control over the AutoSize beast is by use of the Control.MaximumSize and Control.MinimumSize properties.
These properties can be used to keep the difference between the original Control.Size and the eventual size from going way beyond what the developer ever really wanted.
That really does make sense (well, the Control.MaximumSize more than the Control.MinimumSize, but they both make at least some sense). And I would never want to imply otherwise.
Everything still looks okay, right?
Well, let me include the spanner in the works.
Those two properties? Control.MaximumSize and Control.MinimumSize?
They are not included in the localizable .ResX.
This leads to three specific problems:
Now the combination of these first two factors often leads (as you can perhaps imagine) to the kind of bug that goes back and forth several times between the localizer fixing the truncation bug and the tester reporting it with the kind of "the problem is fixed"/"no it isn't" kind of argument that so often can come from looking at two different things and thinking they are the same.
Or make it a core bug -- perhaps only found after everything has been frozen and no one is willing to make changes.
Now with all that said, in the world of Visual Studio, this bug is not such a big deal.
I mean, from their point of view it is really quite unreasonable to even set Control.MaximumSize or Control.MinimumSize to a size that could break localization; in fact, one of the more senior people I talked to about this bug couldn't even see why anyone would set either property in a form meant to be localizable.
Of course I don't know of any other reason why one would set it, which means that someone was admitting to me that the property was a bad idea! But that can be a subject for another day... :-)
Now the WinForms people are not being arbitrary about this judgment; the bug, which has existed since the very initial 1.0 version of the .Net Framework and WinForms, has (I am told) never ever been reported by any other customer external or internal to Microsoft.
Now to Windows it led to hundreds of bugs (and no, this is not an exaggeration; the actual number is even higher though the "even higher" part is due in part to other problems that I'll talk about in some future blog).
Pain in the butt bugs with all those back and forth problems and difficulty pinning the problems down. And so forth.
Windows actually shipped with many of these bugs only partially fixed or worked around.
And some of the worst of the offenders in the dialogs are known by name to people on the localization team, since they know how many bugs they can expect to have to deal with any time one of them is changed.
But reportedly no one else has ever complained about the problem. Ever.
Eventually there will be a fix for this problem, a fix that I guess no one outside of the internal Windows team even cares about, since no one else apparently ran into the problem.
And there will be a KB article describing it (I'll link to it once I find it exists). In case it turns out anyone wants it.
From a social engineering standpoint I wish I had the time, resources, and knowledge to study the factors that can cause a bug to so hugely impact multiple developers spread across teams and groups and divisions and even continents within one large product while never affecting any other project in the entire world.
I can't even try and fathom that one; in fact I get a headache just thinking about it....
John Cowan on 25 May 2010 9:48 AM:
The *real* problem is that developers shouldn't be in control of the presentation features of apps.
Michael S. Kaplan on 25 May 2010 9:56 AM:
As opposed to the rodeo clowns passing by? :-) We assume they are working within the spec provided by program managers who have the advice of UI designers....but as long as localizers can change things I'm happy!
Mihai on 25 May 2010 11:55 AM:
In general I recommend against MaximumSize. What's the point? If forced to some value, then the content is truncated and it is useless. The chances that a tester will notice a truncated string are lower than noticing a dialog that is too big. If one thinks they have to use MaximumSize, and without it content would be too big for the screen, then it is probably bad design to begin with.
And MinimumSize should be no problem if set, not matter the content. If MinimumSize is used on control1 to accommodate somehow another control (align with it, or something), then the form is probably not designed properly.
Last: even if there are no bugs filed, don't assume nobody knows or cares :-)
Over the years I have found quite a few bugs, and also found workarounds for them. Sometimes reported, sometimes not. The time it takes to file a bug and follow up on it is not trivial, and the way some of the bugs where treated did not encourage me to waste^H^H^H^H^H spend the time to file others.
Miral on 25 May 2010 4:31 PM:
The localisation design we settled on in the end for WinForms apps is that the English version needs to allow ~40% extra blank space in each text control for translation expansion, and translators are utterly forbidden from moving/resizing controls.
Why? Because if a control is moved in the translation, and then *later* it is moved in the English version, the translation wins. Since we frequently need to move controls around as things are added, and we don't always do a re-translation pass (we release very frequently, and our customers don't mind a few things in English) this results in overlapping controls, since some of them will move (the ones the translator didn't adjust) and some won't (the ones they did).
(Admittedly, we haven't yet had an Arabic or other RTL language to contend with.)
But I can't think of any case when we've used MinimumSize/MaximumSize for controls -- in general the auto-layout functionality of WinForms is just too weak to be useful. (WPF, on the other hand, excels at auto-layout, as long as you don't use Cider.)
Mihai on 27 May 2010 10:10 AM:
Related to Miral's comment: sounds like a lot of fixed position/size going on there :-)
In my experience the auto-layout features are enough in maybe 95% of the cases.
They are not very intuitive though, so it takes some time to figure out how to use them properly.
In general I am able to make pretty much everything use auto-layout.
But it can also happen to spend a full half-hour on one form to make it work right.
John Cowan on 26 Nov 2010 11:52 AM:
Some UIs were obviously designed by rodeo clowns, yes.
But what I really meant is that presentation features shouldn't be expressed by code, but by something else that is easier for non-developers to change.
Michael S. Kaplan on 26 Nov 2010 11:59 AM:
...and certainly not by something that non-developers (like localizers) don't have exposed to them!
go to newer or older post, or back to index or month or day