Comment On Classics Week: Laying the Foundation for i18n, Brick by Brick

where is the spec? </old joke>

Looks like C# to me....

looks like crap to me

Actually, I think it's Java...

Ok so I've been pretty supportive during this week of classics, but I definitely wouldn't mind seeing an article from the early days and not from a few months ago. It doesn't take much to dig back a little bit further than early 2007.

rjn:

Actually, I think it's Java...

Using .aspx pasges?

rjn:

Actually, I think it's Java...

My guess is that it's C# because of the way the xml tags are in the comments to auto generate documentation. Javadoc uses a different syntax. That's just my guess though.

johnny:

rjn:

Actually, I think it's Java...

My guess is that it's C# because of the way the xml tags are in the comments to auto generate documentation. Javadoc uses a different syntax. That's just my guess though.

Definitely C# because of the xml comments.

anything before this year would be too WhatTheFooky!!

rjn:

Actually, I think it's Java...

Lowercase S for string, XML single-line documentation, rather than two-star Java docs, "foreach" rather than "for", the use of "aspx" and static variable (string.Empty) in lowercase all mean it is not Java.

Jesus! It's ... J# !!

Brick by brick, indeed.

So nested if's are the paramount of optimization?

So what's the WTF?

I hope it's not something as lame as "he should have used a hash table for speed". Because if the searched string is near the top of the list (i.e. most people access the "eng" pages), linear search can indeed be faster than extracting a three-character substring and calculating a hash checksum for it.

H|B:

Brick by brick, indeed.

So nested if's are the paramount of optimization?

... inside a loop!

This gets called for EVERY request so it's as optimal as possible!

Somehow, I don't think that's true....

Captcha: pointer. How apropo.

alex:

From what I understand, it boils down to this: they work less and play more; when not working or playing, they drive tiny little cars.

Dude,
not cool.

Somehow, I think this makes sense to me... I guess if the inputted strings might be 'english' or 'danish', this would be the best way to do it. And since its going by url (if I've understood correctly) then it could catch some PICNICs.

Also, the real WTF is Worse Than Failure's own way of dealing with multiple languages.

The real WTF is that it's being checked every request. For the love of logic, why???

I think we've established that it's ASP.NET (the language is irrelevant).

If the end purpose is determining which language to present then this is a WTF because multiplle languages can be handled using the System.Globalization namespace.

If it's to handle differing products across multiple databases in different countries then we have to raise the other eyebrow and ask why this is also done by plumbing multiple copies of the same pages, unless they're running an http handler that does something very convoluted and worthy of the WTF code comp.

Perhaps this function was written by a student, Deployed by the lecturer who had set a task to optimize his p**s poor attempt at web app architecture.

Nomen est omen:

So what's the WTF?

I hope it's not something as lame as "he should have used a hash table for speed". Because if the searched string is near the top of the list (i.e. most people access the "eng" pages), linear search can indeed be faster than extracting a three-character substring and calculating a hash checksum for it.

I'd guess that the wtf is the fact that there will be an identical copy of the entire site in each language folder, and that the script getting run (instead of a 404) should mean that the language code in the url is correct. Also the fact that it bothers checking the characters individually instead of just using a string compare.

Nomen est omen:

So what's the WTF?

I hope it's not something as lame as "he should have used a hash table for speed". Because if the searched string is near the top of the list (i.e. most people access the "eng" pages), linear search can indeed be faster than extracting a three-character substring and calculating a hash checksum for it.

Well for one, he's checking character by character when you can just compare strings in C#. Those if statements could be replaced with a simple url.SubString(1, 3) == str.

But the REAL wtf is that C# and ASP.Net has a framework for dealing with globalization. It uses resource files, and will swap in the correct localized resource file based on your browser's language and location. He's ignoring that and doing his own home-brew solution.

The real WTF is that it's being checked every request. For the love of logic, why???

Wouldn't you want to verify the validity of every request?

If the end purpose is determining which language to present then this is a WTF because multiplle languages can be handled using the System.Globalization namespace.

My primary language is English. I wouldn't want web sites to look at my browser settings to determine my preferred language. Some sites have fabulously sucky translation... I want to select on a site-by-site basis.

This is even more important when I go in a web cafe in a foreign country. Try to use google abroad one day; how's your Korean...?

Country != preferred language; browser's idea of preferred language != preferred language. Those little flags at the top of web sites are really a nice way of handling i18n. A lot of web frameworks get this wrong.

[quote]Well for one, he's checking character by character when you can just compare strings in C#. Those if statements could be replaced with a simple url.SubString(1, 3) == str.[/code]
That is likely to be a tiny bit slower, due to creating an extra object. Although it is questionable whether all this micro-optimization is really worth it in the first place. Perhaps, after some measurement, one could conclude that subString() would be quite sufficient. Not really WTF-grade stuff though...

As to globalization frameworks; most of those tend to suck. Speaking both as a www user and a coder. Many are also single-language or single-platform "solutions". E.g. resource files can get a pain in the neck when you have to translate pieces of text out of the context in which they appear in the HTML file. Been there, done that.

Maybe Windows' way of doing things would have worked in this case. Or maybe not. The WTF itself doesn't really show there is a WTF here, other than probably the poster being WTFishly arrogant in thinking that hash tables are "of course faster, what a n00b the guy who wrote the loop must have been".

Two posts earlier I wrote: "My primary language is English." The post makes a bit more sense if you know I meant to write "My primary language is not English." :-)

hey dude, "deu" stands for deutsch which means german in... german and certainly not "deulish".

I have no problem with the three nested loops, which will be faster than a string comparison.

However, what if there is a file called (say)

/deutronomy/data.htm

Uld: Alex knows this, he's just being silly.

[quote}

[quote]Well for one, he's checking character by character when you can just compare strings in C#. Those if statements could be replaced with a simple url.SubString(1, 3) == str.[/quote]

That is likely to be a tiny bit slower, due to creating an extra object.
[/quote]

Just to be a nitpicker here... when you access the characters of the string by index, it will create a new char array based on the string from which the indexed character will be returned, so no, both are suboptimal.

If you are in .NET 2, do a String.Compare(string1, string2, StringComparison.OrdinalIgnoreCase), which will be the fastest way. (There is no need to du linguistically correct comparison on two url-s)

And in .NET 1.x you can use String.Compare(strin1, string2, true) indicating that you need a case insensitive ordinal comparison.

Is that it doesn't verify the length of the string.

It should check that str[4] == '/', or something.

Otherwise /lang/engXXX/foo.aspx passes and this validation is worthless!

Please believe me that I don't say this lightly, but you people are idiots. The Real WTF is that this function does nothing useful. It examines a substring of the URL and returns it iif that substring is found in an array of substrings. But since there's no other data attached to the array, actually using the language code for anything would entail another lookup (at which point an invalid language code could be caught). The Real WTF, in other words, is that twenty lines of "cleverness" is being used as a substitute for substr. And then that dozens of soi-disant gurus will take that code snippet and argue about for-loops.

And furthermore, the URL "/e" fails with an IndexOutOfBoundsException (or whatever it is in C#).

The *real* WTF is that it's written in ENGLISH.

hey dude, "deu" stands for deutsch which means german in... german and certainly not "deulish".

As we pointed out when this WTF was shown first time. Obviously no one was able to read any comments of the reposted WTFs. Would have been really much work, when you're not writing them new.

actually DEU or GER both stand for German, the ISO 639-2 language codes translate to English. The reason that German has an additional code because the ISO 639-1 codes translated to the target language and GER is not a logical succesor to DE.

iGoogle's i18n is ridiculously wrong. I can understand using the local language as a first guess. But you must sign-in to ig, so why isn't my preferred language used then instead of the local one?

All we have to critique is the actual code segment shown... we don’t know enough about the app to decide if using the URL to distinguish language was a good idea or not. The site may be using URL virtualization and the .NET localization and globalization techniques are not always the right way to go.

The only WTF I can see in the code is that the developer thought it actually mattered to optimize this block simply because it would be called for each request. He was wrong, and demonstrates that he utterly failed to understand the environment in which his code would operate.

And the other WTF is that so many people in these comments commenced to make the same mistake and start arguing if String.Compare() or Substring() or whatever else was a faster means of comparing the URL to the known languages than the nested if statements the initial developer used. That is the exact same mistake that lead the initial developer to write this junk in the first place.

It DOES NOT matter how you compare the strings!

This gets called once per REQUEST. If you look at the amount of work ASP.NET (or any server side web platform) performs on each request you'd quickly see that optimizing a simple match between a single string and a finite (and small) list of possible values is very much like pissing in a river and worrying that you might be causing a flood downstream. The original developer wasted an enormous amount of time (failing) to optimize something that won't have any appreciable impact on performance --that is the WTF here.

The way I see, globalization frameworks should work like this:

1) check user cookie. If he has set some specific language, use it
2) nothin' in the cookies? then ask the browser
3) figure by the ip? (optional)
4) all failed? well then, fall back to app's native language

Anyway, the top-left/right language flags should STILL be available if the user would rather read the site in another language.

CAPTCHA: paint. Insert a witty remark here.

Yeah, but if 100000 people were pissing in the river at the same time, it would start to become an issue.

rjn:

Actually, I think it's Java...

Did Java gain the foreach keyword recently?

Nomen est omen:

Country != preferred language; browser's idea of preferred language != preferred language. Those little flags at the top of web sites are really a nice way of handling i18n. A lot of web frameworks get this wrong.

Strongly agreeing here. Another annoying thing: In the Windows region settings, there's an option for what encoding to assume when a non-UTF-8 encoding is encountered. I have this set as Japanese (which I assume is Shift-JIS, but they just say "Japanese") because I use a lot of Japanese software, and not all of it is UTF-8. But I have my locale set as English (United States). But lots of programs use that former code page setting to determine what language I want. For example, when I download the installer for Nero, I'm not given any language options. It seems to just have every language built into the installer. But there is no way to choose. It just picks Japanese automatically and installs everything with Japanese. Sure I can read it, but I'm not the only one using that computer. I want it in English. But the only way to get the English language files is to either rip them out of the installer executable, or download them separately.

Anonymous coward:

rjn:

Actually, I think it's Java...

Did Java gain the foreach keyword recently?

Java just overloaded for. If the code says

for (int i : myIntList) { ...}

it is exactly the same as c#'s

foreach (int i in myIntList) { ...}

alex:
From what I understand, it boils down to this: they work less and play more; when not working or playing, they drive tiny little cars.

Dude,
not cool.

What's wrong with an american taking the piss out of Europeans? I'm from England: we do it all the time.

The real WTF is that his XML comments are incorrectly formatted (param comment will get ignored)

Flash:

Yeah, but if 100000 people were pissing in the river at the same time, it would start to become an issue.

a web server recieving 100000 CONCURRENT connections at EXACTLY the same time? Be serious... you will be bottle-necked by other resource limits long before you overload the CPU or RAM with this simple string check. If nothing else, you'll have hit the network bandwidth limits and it wont matter if it takes a couple extra cycles to compare your strings.

snqow:

The way I see, globalization frameworks should work like this:

1) check user cookie. If he has set some specific language, use it
2) nothin' in the cookies? then ask the browser
3) figure by the ip? (optional)
4) all failed? well then, fall back to app's native language

I have no problem with this kind of localization conceptually, but there is at least one major argument for supporting language choice by URL instead of, or in addition to using the browser preferences.

Consider search bots... if you support content in a dozen different languages, with english as the default. Then suppose you can get to the non-english languages by having a cookie or a browser that supplies a language preference. But how then will a search spider that doesn't provide a language choice or support cookies be able to index your non-default language content?

Sure the search spider will get to the default language version of your site and index that... but that doesn't help the german speaking user trying to search for german content phrases.

By avoiding URL based language choice you also avoid getting your site indexed.

It did, in Java 5 or 6 (can't remember which), but I'm still convinced due to the .aspx extension and the XML method comments that it's C# under ASP.NET.

.net also allows you to load up a Satellite assembly (basically a localised resource file) dynamically..

so, often what I have done is allow the user to click on a flag / dropdown which represents their Lang-locale. From there just pass the selected language into a wrapping resource file getter class and have that select the correct resource file to read from.

myAssembly.en-gb.dll
myAssembly.en-us.dll...



And yes, this is C#

Speaking of classics: Microsoft is inspired by the Wooden Table Format (let's call it WTF for short) to promote Dynamics in Belgium.
I knew they actually do read worsethanfailure.com!

Many of us do....

Many of us do....

Many of us do....