16999 - [I18N] "Submit Query"/"Reset"/"Browse..." hard coded into html.css

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

The file that contains presentation information for HTML elements in the content
window, html.css, has default caption values for Input type="submit" and
type="reset" hard-coded into them:

content: "Submit Query";
..
content: "Reset";

Comment 1

[Frank Tang]

I really don't think putting "Submit Query" and "Reset" into a CSS file is "HARD
CODED", after all, you need to store these string somewhere. But I do agree that
these string probably should store in some other kind of text file, say a string
bundle (locale sensitive property file)

Reassign this to hyatt since he is the one show in cvs blame for that two line.
Ray Chen and Tao could help you to make the right decision and provide the right
tool to do the right thing.

Hyatt, please talk to Ray or Tao, I know you are pretty busy. I think they could
help you to solve this issue if you can tell them where to look at this issue.
Hyatt, please reassign this to the right person who OWN this CSS (and in
particular the code which look at the content of this CSS) if you are not the
right person. Thanks.

Comment 2

[David Hyatt]

not my bug. rickg gets it.

Comment 3

[rickg]

Eric -- can you please resolve this. Thanks.

Comment 4

[Eric Pollmann]

Frank, you are the i18n expert.  Where is it customary to store localized
strings like this?  How can I get access to them from, say:

layout/html/forms/src/nsFormControlFrame::GetValue() ?

When we change languages, as in the demo we saw a few weeks back during the
seamonkey all-hands meeting, how are all of the other button labels getting
updated?  Can't we use this same mechanism to explicitly set a value for the
submit button?

Comment 5

[tao]

Static UI strings in XULed UI are defined in the *.dtd associated with the
 *.xul. Dynamic resource strings are defined in *.properties files and can be
retrieved via StringBundleService in C++ or JS code. Look at this doc below
for XUL & DTD issues:

	http://www.mozilla.org/projects/intl/xul-styleguide.html#l10nhow

And, this doc for StringBundle:

	http://www.mozilla.org/projects/intl/string-resources.html

Sample usage can be found here for C++ code:

http://lxr.mozilla.org/mozilla/source/exte nsions/cookie/nsCookie.cpp#234

and here for JS code:

http://lxr.mozilla.org/mozilla/source/intl/strres/tests/strres-test.js#104


Also the "Components" field of this bug shall be "Layout" instead of "I18n".



Thanks

Comment 6

[Eric Pollmann]

After careful consideration, I've decided that I probably won't get this bug in
for M12.  Currently I have nearly 50 bugs scheduled for M13, so there is a
possibility that this bug may need to be moved out farther still.

Comment 7

[tao]

CC msanz. We shall try to resolve this no latter than M13. Otherwise, there
is a great possiblity that you're gonna see English UI in a localized product...

Comment 8

[msanz]

Any bug that impacts localization needs to be fixed by M13 because we are
localizing beta. And we need it before M14 because we need to work on the files
a month prior to beta.

Comment 9

[ekrock's old account (dead)]

Marking [I18N].

Comment 10

[msanz]

resources have to be localizable by beta1 at most, marking BETA

Comment 11

[Eric Pollmann]

Due to regressions caused by my fix to bug 20315, I will probably not be able to
get to this today.  Marking M14 and I'll try to get it in early M14 if possible.

Comment 12

[Phil Peterson]

Laura, is this a beta stopper?

Comment 13

[leger]

Putting on PDT+ radar for beta1.

Comment 14

[Eric Pollmann]

The more time I spend with this bug, the more I think creating localized
versions of html.css is an easier and possibly better solution to this bug...

I've made some progress here, but am currently stuck.  Rod, this seems like an
area you might be familiar with, can you help me out?


What I have done:
 - nsGfxButtonControlFrame to grab a string bundle and gets localized default
   labels for submit and reset buttons
 - these strings are used to compute the button size
 - created a properties file, and modified makefiles to export this


What I need help with:
 - Determining if a button is a file input ("Browse...")
 - Generate a text frame with the localized string as the child of the button.
   (I've tried setting the style content but it doesn't work reliably)

Right now the buttons get their text from a .properties file and appear the
right size, but currently just appear as gray boxes (except when they
occasionally appear with text, which I can't explain).

I'll try to scrape together the diffs.

Comment 15

[Eric Pollmann]

Attachment: Zip of diffs (instructions follow)

Comment 16

[Eric Pollmann]

To add the diffs to your tree (and build)
(Works on un*x and Windows if you change / to \ :)  )

save the attachment as diffs.zip
cd $MOZROOT/mozilla
unzip diffs.zip
cd layout/html/document/src
patch < DIFF
make
cd ../../forms/src
patch < DIFF
make
cd ../../../build
make

I added the changes needed to create a text frame, and they seem to work.
The only thing lacking from a solution here is to determine if a button frame is
a part of a file input frame.  This should be done in
nsGfxButtonControlFrame::GetDefaultLabel() in place of the if (NS_FORM_BROWSE ==
type) which doesn't work.

Comment 17

[Eric Pollmann]

Perhaps the lack of sleep is getting to me.  I'll add a check - get the button
frame's parent, and if it is a file input use the "browse..." localized string. 
Of course, any other suggestions are appreciated, thanks!  :)

Comment 18

[tao]

Hi, Erik:

Are you still seeing the grey button without text? Have you checked that if the
retrieval of the string was successful?

Comment 19

[Eric Pollmann]

I solved the grey buttons problem but have caused a new one now.  Will be
working on this tonight.  (Yes, the retrieval of the localized text is
successful.)

Comment 20

[Eric Pollmann]

Attachment: Patch to layout/html/document/src/html.css

Comment 21

[Eric Pollmann]

Attachment: Patch for layout/html/forms/src

Comment 22

[Eric Pollmann]

Attachment: New properties file

Comment 23

[Eric Pollmann]

Attachment: New MANIFEST_PROPERTIES file

Comment 24

[Eric Pollmann]

The above four attachments are a complete fix for this bug.  I need to get this
code reviewed and approved.

Comment 25

[Eric Pollmann]

Reviewed by Rod (Thanks!)  Making a few small changes before seeking approval.

Comment 26

[Eric Pollmann]

Getting review on changes to NGLayoutBuildList.pm (for Mac build)

Comment 27

[Eric Pollmann]

Just checked in the fix.

If you have a build compiled on your machine, you can verify like this:

Open the file I'm about to attach in the browser.
Open up the HtmlForm.properties file in a text editor. 
  mozilla/dist/bin/chrome/layout/locale/en-US/HtmlForm.properties on Linux
  mozilla\dist\Win32_D.OBJ\bin\chrome\layout\locale\en-US\ on Win
  mozilla:dist:viewer_debug:Chrome:Layout:locale:en-US: on Mac

Edit the contents of HtmlForm.properties to something like:
Reset=Esetray
Submit=Ubmitsay Eryquay
Browse=Rowsebay...

Click reload

The buttons with default labels should show the new 'localized' labels that you
saved.  Thanks!

Comment 28

[Eric Pollmann]

Attachment: test case

Comment 29

[tao]

Hi, Teruko:

Would you please alos test languages in double byte charsets such as CJK?


Thanks

Comment 30

[Eric Pollmann]

See bug 28691, leaks/bloat caused by this checkin. :(

Comment 31

[Teruko Kobayashi]

I cannot verify this until 28900 is fixed.

Comment 32

[Eric Pollmann]

I just checked in a fix for 28900, thanks for noticing that important omission!

Comment 33

[Teruko Kobayashi]

I tested this in 2000022909 Win32 build.  I changed the HTML 
elements to Japanese in HtmlForm.properties, but the Japanese buttons do not 
show correctly.

Comment 34

[Teruko Kobayashi]

Attachment: Modified HtmlForm.properties file

Comment 35

[Teruko Kobayashi]

Attachment: Japanese buttons do not show correctly

Comment 36

[tao]

Hi, Teruko:

The properties file needs to be in escape-unicode instead of native encoding.
Is this what it is now?

Comment 37

[Teruko Kobayashi]

Tao,  thank you for remind me.  I change back to Resolved as Fixed.  

Comment 38

[Teruko Kobayashi]

I verified this in 2000022909 Win32, Linux, and 2000030108 Mac build.