Original status: 5-Cause Known; Suggested Status: NEW


These items should be added to the Keywords: RELNOTE
These items should be added to the Status Whiteboard: DOCS WAV_APPROVED


Original submitter: kfrank

Description:
build 025
for design time, the labels of composite components seem to now come from
bundle files, at least for most, but for runtime, they don't.

I'm not sure of which bundle file has those labels - 
I am localizing the messages.properties of the theme jar files,
and also the Bundle-DT or JSF of
dataprovider, html-dt, jsf-api-dt, webui-dt
and
jsf-impl/Resources.properties

If this is issue in BH componments/runtime, can this issue be left open
here since it is seen in creator and will help with tracking.


xxx@xxxx 2005-06-06 03:05:35 GMT


see commeonts for more up to date descrption

xxx@xxxx

Description (Entry 2):
also - Palette - layout - add property sheet, then add a new section, (context
menu - add property sheet section) then in Property Editor of the Property Sheet
Component check jumpLinks option, 
words "back to top" appear in design which do not come from bundle file

Description (Entry 3):
additonal areas

basic table - choose in properties all the check boxes so additional
buttons appear on table - for designtime can't see the labels
but at runtime these too dont come from localized labels

the labels for the buttons just say
  as does the column names

the tooltips for the buttons not
from bundle
Select items to be displayed
Deselect items currently displayed
deselect current item
multiple-column sort
clear all sorts

and the tooltips under each column name thtat asyas
click to make this the primary sort col ....
click to sort descending

am guessing all other possible tooltips or labels

xxx@xxxx

Description (Entry 4):
A technical article needs to be written to explain the process for writing
localized Creator web applications.

Evaluation:
I have tested and confirmed that theme messages can be localized. Here is what I
did:

I built a version of defaulttheme.jar that contained, in addition to
messages.properties, a localized version, messages_fr.properties. Note that this
is built as one JAR, defaulttheme.jar

I started Creator in a French locale, by passing -Duser.language=fr_FR to the
start-up script.

I dropped an instance of AddRemove on the designer, and the button text and
labels were those found in the French messages file.

So, the question is, when we ship localized versions of Creator, can put the
localized theme messages into the same defaulttheme.jar? This will happen by
default if you put them in the same directory as the default messages.properties
and then do a build.

Evaluation (Entry 2):
That's not the l10n model we follow. We have localized jar files
in separate jar files, msg/help only, that live in the locale
subdir of where the en ones live.

Also, having them in the same jar file as en means additions/changes
to base team 10n process, since l10n puts back to translatedfiles module,
not to the cvs of the actual module. This is a big change at this
late date, since l10n work has been ongoing for some time also.

Also, since we have ml release after en one, it means that if all in one
jar, the jar will be different between releases and can be problems for 
support also.

What is needed, IMO, is for all this to be handled the way all other
msgs/labels are handled, that localized message files in localized
jar in locale dir is used; and since the BH code is now in our
cvs, couldnt we make changes to get that to happen ? (even though
original design by other team assumed a different model)

xxx@xxxx

Evaluation (Entry 3):
Unfortunately, the theme architecture that we inherited is not easily modified.
The theme manager assumes that a theme is deployed as a single JAR to the
run-time theme servlet. Even if I could modify the theme manager so that it
picks up message files from the classloader (and not just from the theme JAR) at
design-time, this would not work at run-time, because everything needs to be in
the theme JAR. So, user would see correctly localized labels on the design
surface, but when they deployed, they would see English labels.

I'm upgrading this to a P1, and assigning to Craig in the hope that he has other
suggestions.

Evaluation (Entry 4):
The theme architecture is preventing us from resolving this correctly in the
short time left before Thresher.

Any properties set at by the user at design-time will be deployed, so this much
at least is localizable. The problem is the themes, which is the source for most
messages, and a few labels. We are fixing all the labels by making sure that
there are properties for setting everything at design time. As for the messages,
users will have to construct a localized version of a theme. We should include
instructions about how to do this with the general theme documentation that we
are preparing. 

For real applications, users will have to modify themes anyway, so I think this
is a reasonable work-around.

Evaluation (Entry 5):
We need some more information to see if this is ok for being waived
and for testing what fixes have been done:

1. for "fixing all the labels by making sure that there are properties for
setting everything at design time" --
does it mean that all things reported in other
bugs about some default label or msg on
a dropped component will come from bundle file ?

if so, does this mean that at runtime,
assuming user did not change these,
that the runtime would show these labels/msgs ?

I'd though in this issue it was the case that even if at designtime
some labels/msgs came from bundle files, at runtime they did not -
so wouldnt that same situation be true now, since this bug is
proposed to be waived ?


2. for localized themes, what is the scope and nature of the messages
that user will not see in the localized language - is there a bundle
or other msg files that have these msgs ?

I don't think user of localized should need to have
to construct localized theme just for this purpose, but knowing
the scope/number of msgs will help us see impact on customers.

xxx@xxxx

Evaluation (Entry 6):
Asking for waiver. According to Ken, the localization procedures that i18n
follows cannot be modified to accomodate the Braveheart theme architecture. It
is too late in the development cycle for us to redesign themes. There is a
work-around, which is that users can build their own theme by hand. Also note
that we are adding properties for all labels, so that it will be possible to set
_all_ labels via properties at design-time, and these can be localized by using
EL references to bundle files that the user creates as part of the application.

Evaluation (Entry 7):
I added to workaround section the start of what release notes
might say, emphasizing that regardless of workaround, its needed
to describe the user experience as reported in this issue.

xxx@xxxx

Workaround:
This is info for release note writer since this issue is waived for thresher
but we feel its important that user has additional information:

1. when user of localized product drops certain components on drawing
area, most of them have some seeded default labels or other messages
shown on that component; in best case, all of these labels, etc
should come from localized files

2. But for those that do not, and even for some that do, at runtime,
some of them will not show the localized messages in any case - and that
is the subject of this issue.

3. assumption here is that for these situations, user is prototyping
their app, so that the labels do not have to be meaningful but at least
should be in their own language. For other labels, like some on add/remove
component, some of the labels would be acceptable even for real app,
but in this case, its not clear that even user changing these to their
own would have them show correctly at runtime.

4. in eval and comments, it was mentioned about some workaround
that will be provided; that info would go into release note also.

xxx@xxxx