Re: ASP.NET Internationalization bug?

Mr. Pot,

The Microsoft team has confirmed the bug.

"We were able to reproduce the issue you are seeing. We are escalating this
***bug*** to the product unit who works on that specific feature area. The
product team will review this issue and make a decision on whether they will
fix it or not for the next release"

Cordially,
Mr. Kettle


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:eo2Lf$k2IHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> the bug prevents me from doing it the "right" way for my scenario

What you have been saying all along is that code-behind is "better".

It certainly might be more suited for your purposes, but it's not
"better",
it's only better suited to particular scenarios like the one you describe.

The problem is that you shouldn't generalize your scenario to all
programmers.

For every programming team that works like you do, there's hundreds of
independent
programmers who don't need to use code-behind and who, in fact, encounter
many
unneeded difficulties when implementing code-behind, not the least of
which is the
added complexity of maintaining two pages in synch (the aspx and the
code-behind source).

re:
!> You do seem to have a handle on the internals of ASP.NET.

Seem ? Your generosity astounds me. <g>

I'll be looking forward to the response which your bug filing prompts from
the VS Team.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <nomail@xxxxxxxx> wrote in message
news:OaAr$lk2IHA.528@xxxxxxxxxxxxxxxxxxxxxxx
One last reply...

You can promote the technical merits and effectiveness of mixing content
and code all day long. Once you need/want a designer and a programmer to
work on the same page--at the same time--you need to separate them, which
is where I am. (There are *many* other great reasons, too.) You're not
being there does not turn a bug into a feature.

I'm not trying to get you, or anyone else, to stop mixing content and
code; I'm trying to explain why your, or my, workaround to the bug I've
found is not satisfactory to me. (Even if it were, a but still exists
and should be reported.) You keep asserting that your workaround is just
fine; it's not--it's a workaround--not a solution--because the bug
prevents me from doing it the "right" way for my scenario (keeping
content and code separate), which is something the ASP.NET team has
worked hard to empower me to do easily. It just happens that they missed
a spot, and I've discovered it.

You do seem to have a handle on the internals of ASP.NET. You appear to
not have a handle on some of the practical issues of Web (application)
development.

Cordially,
Lee

"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:%23WNbcpi2IHA.3884@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> its wiring belongs in the content file (.aspx)--not the code file
(.aspx.vb).
!> Sure, I could throw in some classic ASP style, and put a script
element in
!> my .aspx page to keep the wiring in the realm of the designer

One last comment...

You seem to think there's no place for inline code for ASP.NET
programming,
and that the only place where code should be placed in is code-behind.

In fact, inline programming in .aspx pages is just as effective as
code-behind programming,
and there's no reason to assert that anything "belongs" in code-behind,
when inline programming
is every bit as efficient as code-behind.

Your "comparison" of inline aspx programming with the "classic ASP
style" of programming
is meaningless, given that "classic ASP" used interpreted script
technology while inline code
in aspx pages is not interpreted, but truly compiled code.

Add to that the fact that aspx pages are object-oriented and are not,
like ASP used to be,
interpreted in the order the code was written, but in relationship to
the objects created,
and you should understand why you are really comparing apples and
oranges.

My personal preference is using inline code in the aspx pages, and
compiling my
business rules/database access classes to assemblies, from where the
classes
can be easily imported to any aspx page.

Choosing codebehind or inline is very much a question of personal
preference,
not of the inherent superiority of either of the two methods over the
other one.

Ymmv, of course.



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <nomail@xxxxxxxx> wrote in message
news:eE3jN2g2IHA.4572@xxxxxxxxxxxxxxxxxxxxxxx
Juan,

You clearly don't understand, or have not thought about *why* the
ASP.NET team gave us separate places for "design"/content (.aspx files)
and "procedure"/code (.aspx.vb). The ability to separate the 2 was a
huge feature for ASP.NET, from classic ASP.

Even though the particular content affected by the bug I found is not
*visible* Web browser content, it is content none-the-less. Thus, its
wiring belongs in the content file (.aspx)--not the code file
(.aspx.vb). Sure, I could throw in some classic ASP style, and put a
script element in my .aspx page to keep the wiring in the realm of the
designer, but that changes nothing, because it's still programming,
which should be done by programmers in the same place as every other
line of programming in my site: the .aspx.vb pages. Just as badly, it
means I'm achieving my I18N wiring in multiple ways, instead of being
consistent.

By everything else, I meant all other I18N resource "wirings". (But, I
take pride in how "light" my .aspx.vb files are--and how clean my .aspx
files are, too.) You are obviously fine with having the designer(s) to
set up and manage *most* of the I18N wirings, *and* having programmers
to do some, too, (as they should not be doing) since bugs are not bugs
for you if there is a workaround that violates good design practices
and principles. I'm not fine with that.

Are you really an ASP.NET MVP? (Classic ASP, maybe?)

, Lee


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:urCttna2IHA.4476@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> Setting it programmatically is an incorrect implementation
!> when everything else on my page is set declaratively.

Is everything else on your pages set declaratively ?
Think about that for a second.

Why do we have inline scripts and code-behind, if "everything else is
set declaratively" ?

In any case, we've certainly had enough of the "I think that..." back
and forth.

Let's pause this discussion until the "bug" you reported is explained
by the VS Dev team, OK ?
I, definitely, want to see what their explanation is.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=353879



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <nomail@xxxxxxxx> wrote in message
news:eQlpa4W2IHA.4704@xxxxxxxxxxxxxxxxxxxxxxx
Correct implementation? What do you mean by that?

I stated earlier on that I worked around it. It's still a bug.
Setting it programmatically is an incorrect implementation when
everything else on my page is set declaratively. Microsoft offered
declarative (explicit) expressions, and I want to use them--anywhere
and everywhere I choose in accordance with how they are stated to
work. When I find one that doesn't work, it's a bug; it's not a case
of my doing something incorrectly. I love Microsoft Visual Studio
2008; but, I won't tolerate bugs, or suck them up as, "Oh, I must be
doing it wrong since it doesn't work--even though it should."

, Lee

"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:%23xhBpuW2IHA.2384@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> ASP.NET should make it easy for me--and, it does,
!> but there is a bug in the implementation.

The fact that you *can* set xml:lang programmatically, and that you
*did* set it that way,
as I did, should tell you that it isn't much of a bug, but a
question of using the correct implementation.

But, again, please let us know what the reply to your bug report is.



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <nomail@xxxxxxxx> wrote in message
news:%239PIQvU2IHA.2384@xxxxxxxxxxxxxxxxxxxxxxx
Juan,

My use of language and culture in ASP.Net is a bit different than
most. I have registered numerous country-code-specific domains
(mysite.ca, mysite.co.uk, mysite.com.au, etc.), which resolve to a
singular "ASP.Net Web Site". Nothing new there. However, I'm not
doing the ASP.Net usual of letting the user agent (HTTP header
'accept-language') determine which language visitors get; I have
the country-code TLD drive it. Also, it's not just the language of
my content that varies by cc TLD, it's the content, too; but, lang
attributes play a critical role in informing user agents (including
search engine bots) for what "country" my content is aimed.

I have already found, first-hand, that the better of the major
search engines use the cc TLD *and* the HTML lang/xml:lang to
determine whether a domain's documents
(mysite.com.au/my-document.aspx) should show up when a searcher
searches with the 'Only from Australia' checkbox checked on
Live.com, for example.

I'm not setting lang attributes for fun; I'm doing it to correct
search engine results. ASP.NET should make it easy for me--and, it
does, but there is a bug in the implementation.

I appreciate your interest and effort to help.

, Lee


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:uBUnQxT2IHA.4164@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> versus the spirit of what we're trying to accomplish: telling
user agents who our
!> intended audiences is, by language, as best we can...which is
why I'm *also*
!> setting lang in the HTTP headers and in page meta tags

What ? You don't set a language/culture in web.config, too ?
There's a use for overkill ! ( only kidding... )

I don't see too clearly the purpose of declaring a single language
for a web page.

I do see a use for declaring specific language attributes in a
*collection* of xml documents,
so that individual documents can be parsed for a particular
language content.

But, ymmv...

I'd still be interested in knowing what the reply is to your bug
report.
I bet you'll get back : "That's by design". <g>

Don't forget to let us all know what happens with that, OK ?
Thanks for an interesting discussion.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <nomail@xxxxxxxx> wrote in message
news:en1PZVT2IHA.524@xxxxxxxxxxxxxxxxxxxxxxx
Juan,

In theory, I like your idea of investigating "the standard"; but,
in practice it has serious problems, as it often does. First,
you are referring to the XML standard, which is not as
appropriate as HTML and XHTML standards. Second, none of them are
crystal clear on best practices for I18N. There is a lot of
*legal* (by the standard) syntax, that makes no sense, or makes
some sense without being clearly best. The W3C site often states
something to the effect of, "some are doing this, some are doing
that, on your own site, at least do something and only time will
tell what is best."

Check out these fine examples, which mirror my syntax, on the W3C
site.

Internationalization Best Practices: Specifying Language in XHTML
& HTML Content
http://www.w3.org/TR/i18n-html-tech-lang/#ri20040429.092928424


Tutorial: Declaring Language in XHTML and HTML (Draft)
http://www.w3.org/International/tutorials/language-decl/en/slides/Slide0160.html

Juan, you wrote:
But, it seems to me that setting xml:lang for the html tag's
*attribute* values is unneeded, since they must
be in English, and they must be attributes set to a language
identifier, as defined by IETF RFC 4646
(http://www.ietf.org/rfc/rfc4646.txt).

You're not setting it for "the tag's *attribute*", you're setting
it for the *contents*, all contents, of the element (unless
overridden by a sub-setting), which makes perfect sense so that I
don't have to set it individually on every child element--that is
the power of a hierarchy! You seem to be focused on the
technical, with some misunderstanding, versus the spirit of what
we're trying to accomplish: telling user agents who our intended
audiences is, by language, as best we can...which is why I'm
*also* setting lang in the HTTP headers and in page meta tags.

, Lee


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:OYI4upK2IHA.5140@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> I found an MSDN document that explains why what I'm trying to
do should work

Lee,

From :

http://www.w3.org/TR/REC-xml/

"A special attribute named xml:lang may be inserted in documents
to specify the
language used in the contents and attribute values of any
element in an XML document."

If anything, I can see xml:lang being declared for specific
content values, for example :

<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>

Then, an xml parser could identify regional US and British
spellings but, given that *all* the attribute values
must be in English in an html doc, what would be the purpose of
declaring xml:lang for the html markup ?

A similar explanation is given here :
http://www.simonstl.com/xmlprim/xmlupdate/atts.html

---000---
<SECTION>
<DESCRIPTION xml:lang="en">
Caesar begins by describing the geography of Gaul.
</DESCRIPTION>
<QUOTE xml:lang="la">
Gallia est omnis divisa in partes tres, quarum unam incolunt
Belgae,
aliam Aquitani, tertiam qui ipsorum lingua Celtae, nostra Galli
appellantur.
</QUOTE>
---000---

That's perfectly good usage for xml:lang, as a parser could
selectively identify content in different languages.

But, it seems to me that setting xml:lang for the html tag's
*attribute* values is unneeded, since they must
be in English, and they must be attributes set to a language
identifier, as defined by IETF RFC 4646
(http://www.ietf.org/rfc/rfc4646.txt).

So, I think that requisite pretty well establishes the futility
of setting xml:lang for all the attributes in an html document.

If anything, it seems that the xml:lang attribute is included in
the
html server tag for compatibility purposes, or perhaps out of
ignorance.

If there's a need to identify that the *contents* of a
particular markup tag are in a
specific language, that identification can be included in the
tag itself, for example :

<div lang="MX-es" xml:lang="MX-es">
Algo de contenido en español mejicano.
</div>

That makes a lot more sense than setting xml:lang for the
attribute values in the html tag.



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <no.spam@xxxxxxxxxxx> wrote in message
news:%23ocUnoI2IHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
I found an MSDN document that explains why what I'm trying to do
should work.

ASP.NET Web Server Controls Overview
http://msdn.microsoft.com/en-us/library/zsyt68f1.aspx

Note the distinction between HTML Server Controls and Web
Server Controls in the document. Also, note the explanation
of "pass-through" attributes for HTML Server Controls.

Two quotes that sum it up:
1. Any HTML element on a page can be converted to an HTML
server control by adding the attribute runat="server".
2. You can add any attributes you need to an HTML server
control and the page framework will render them without
any change in functionality.

, Lee

"Lee C." <no.spam@xxxxxxxxxxx> wrote in message
news:Oe38JYI2IHA.4772@xxxxxxxxxxxxxxxxxxxxxxx
Juan,

I appreciate your trying to help, but you're wrong, and you
are the one who is confused. :]

I am *not* disputing that when inserted programmatically, the
xml:lang attribute renders to the browser. I did just
that as a work around (right after I discovered this bug);
but, I should not have to.

I am *not* confusing html attributes with runat="server"
attributes, as you call them. Using your logic, none of the
declarative (html) attributes should render to the browser
after I add the runat="server" in ASP.NET; yet all of them
(xmlns, lang, and dir) do--except xml:lang.

I started with an html element with 4 attributes (xmlns, lang,
xml:lang, and dir) all set declaratively. With *no*
5th attribute of runat="server", all 4 attributes render. If
I add the 5th attribute of runat="server", which does
not and should not render, I no longer get all 4 attributes
that should render (xmlns, lang, xml:lang, and dir), I
only get 3 (xmlns, lang, and dir). My logic says I should get
4, your says I should get 3? It would be 4 or 0, and
4 is right. Not 0...and not 3.

When I add runat="server", it does not magically make the
xml:lang attribute a server-side attribute, while keeping
the other three attributes as "html" attributes. All four are
still "html" attributes--which should render.

I think the simplification of my example may be confusing you.
It is odd that, in my example, I set runat="server"
but do not have any server-side attributes. (I have all 4 as
literal strings, for simplicity of an example.) Well,
in my real-world use, I do have server-side attributes, which
I want set declaratively (no code-beside and no
script). I have:

<html runat="server" xmlns="http://www.w3.org/1999/xhtml";
xml:lang="<%$ Resources:GlobalLang, ContentAudienceLanguage
%>"
lang="<%$ Resources:GlobalLang, ContentAudienceLanguage %>"
dir="ltr">

Both of those declarative explicit localization expressions
should work without my having to write any more
"procedural" (code-beside) code or script. It actually does
work fine for the lang attribute--as it should; but not
for the xml:lang attribute--***which is a bug***.

, Lee

"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:u0WzB9H2IHA.4188@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> I think you are misunderstanding, Juan.

Well, I think you are misunderstanding *me*.

re:
!> I had the xml:lang attribute in the html tag
(declaratively), like this:
...and it renders to the browser, as it should.

Yes, because it's standard html.

re:
!> If I simply add runat="server"

That declares the control to run server side.

For any attribute to be programmed server-side you need a
script,
just as you need a script to modify any server control's
attributes.

Did you run the sample page I sent ?

It iterates throught the attributes for the html server
control,
and shows that the xml:lang attribute *is* added
programmatically.

re:
!> If I simply add runat="server", leaving in the xml:lang
attribute that
!> renders without runat="server", all of the (declarative)
attributes are
!> rendered to the browser--except the xml:lang attribute!
That is a bug.

I think you're confusing html attributes with runat="server"
attributes.

Html attributes can be inserted in normal html.
Server-side attributes must be inserted in code.

Maybe I'm not explaining this as well as I should.
Try to get someone else's opinion on this matter, if you
don't accept mine.



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <no.spam@xxxxxxxxxxx> wrote in message
news:enam1gH2IHA.4552@xxxxxxxxxxxxxxxxxxxxxxx
I think you are misunderstanding, Juan. I had the xml:lang
attribute in the html tag (declaratively), like this:

<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en-US"
lang="en-US" dir="ltr">

...and it renders to the browser, as it should.

If I simply add runat="server", leaving in the xml:lang
attribute that renders without runat="server", all of the
(declarative) attributes are rendered to the browser--except
the xml:lang attribute! That is a bug.

<html runat="server" xmlns="http://www.w3.org/1999/xhtml";
xml:lang="en-US" lang="en-US" dir="ltr">

Cordially,
Lee


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in
message news:eyrwjUH2IHA.3920@xxxxxxxxxxxxxxxxxxxxxxx
Here's a full example which shows that the xml:lang
attribute is added programmatically :

attributes.aspx:
----------------------
<%@ Page Language="C#" AutoEventWireup="True" %>
<html xmlns="http://www.w3.org/1999/xhtml"; runat="server"
id="Myid" >
<script language="C#" runat="server">
void Page_Load(Object sender, EventArgs e)
{
Myid.Attributes.Add("xml:lang", "es");
Message.InnerHtml = "<h4>The html control attributes
collection contains:</h4>";
IEnumerator keys = Myid.Attributes.Keys.GetEnumerator();
while (keys.MoveNext())
{
String key = (String)keys.Current;
Message.InnerHtml += key + "=" + Myid.Attributes[key] +
"<br />";
}
}
</script>
<head id="Head1" runat="server">
<title>The html control attributes collection</title>
</head>
<body>
<form id="Form1" runat="server">
<h3>HtmlControl Attribute Collection Example</h3>
<br />
<span id="Message" enableviewstate="false" runat="server"
/>
</form>
</body>
</html>
----------------

I don't think it's a bug to have to add an attribute
programmatically,
because the runat="server" tag only *declares* the html
control as a programmable control.

To actually program it, you must use a script.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Lee C." <no.spam@xxxxxxxxxxx> wrote in message
news:e0rLaPG2IHA.4772@xxxxxxxxxxxxxxxxxxxxxxx
Thanks, Juan.

I already added similar code to a page event in my
masterpage code-beside.

elHtml.Attributes.Add("xml:lang",
Resources.GlobalLang.ContentAudienceLanguage)

To me, that is a temporary workaround. I still want to
understand whether the "eating" of the attribute I
originally
posted about is a bug, or if this is actually happening
for a reason.

Cordially,
Lee


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in
message news:%23gBUqSC2IHA.4772@xxxxxxxxxxxxxxxxxxxxxxx
Hi, Lee.

re:
!> <html runat="server"
xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en-US"
lang="en-US" dir="ltr">
!> no xml:lang attribute is rendered to the browser!
!> Remove the runat="server", and, voila, the xml:lang
attribute is rendered.

Try this :

<html xmlns="http://www.w3.org/1999/xhtml"; runat="server"
id="someID">

<script runat="server">
someID.Attributes("xml:lang") = "en-US"
</script>



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================

"Lee C." <nomail@xxxxxxxx> wrote in message
news:O%23KsAQA2IHA.4572@xxxxxxxxxxxxxxxxxxxxxxx
I think I have discovered a bug in ASP.NET, related to
I18N.

In ASP.NET 3.5 I have to set runat="server" on the html
element to use explicit expressions. It appears that
ASP.NET
eats the xml:lang attribute on the html element when it
is set to runat="server".

Of course I want to replace the hardcoded "en-US" values
with (resource) explicit expressions; but, for
simplicity,
try this:

<html runat="server"
xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en-US"
lang="en-US" dir="ltr">

...And you will find that no xml:lang attribute is
rendered to the browser! Remove the runat="server", and,
voila,
the
xml:lang attribute is rendered. :[

...Any ideas?

Cordially,
Lee












































.

Relevant Pages

  • Re: ASP.NET Internationalization bug?
    ... I'm trying to explain why your, or my, workaround to the bug I've found is ... inline programming in .aspx pages is just as effective as ... I don't see too clearly the purpose of declaring a single language ... HTML and XHTML standards. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET Internationalization bug?
    ... What you have been saying all along is that code-behind is "better". ... For every programming team that works like you do, ... I'll be looking forward to the response which your bug filing prompts from the VS Team. ... I have already found, first-hand, that the better of the major search engines use the cc TLD *and* the HTML ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET Internationalization bug?
    ... The Microsoft team has confirmed the bug. ... For every programming team that works like you do, ... I don't see too clearly the purpose of declaring a single ... which is not as appropriate as HTML and XHTML ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET Internationalization bug?
    ... The Microsoft team has confirmed the bug. ... For every programming team that works like you do, ... My use of language and culture in ASP.Net is a bit different than most. ... I have already found, first-hand, that the better of the major search engines use the cc TLD *and* the HTML ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET Internationalization bug?
    ... Let's see what Microsoft's VS bug team says about the bug you filed, ... My use of language and culture in ASP.Net is a bit different than ... I don't see too clearly the purpose of declaring a single language ... appropriate as HTML and XHTML standards. ...
    (microsoft.public.dotnet.framework.aspnet)