In order to brand Mozilla, "Mozilla" in the UI has to be replaced with the brandname. In DTDs, we have entities for that (they access brand.dtd). We need something similar for string bundles. It is not reasonable to replace ~70 instances of "Mozilla" (not counting the appnames like "Navigator", "Mail" / "Mailnews" etc.) *for each release*. Please fix ASAP - it will help Netscape as well, should it decide to leverage Mozilla translations. As for the implementation, I will start a thread in .i18n.

Importance: With this bug fixed, langpacks of languages the provider doesn't even know might be possible and easy. With this bug, creating a single rebranded translation is a lot of work (just did it). So, this bug is practically a blocker for localized Beonex. Please fix ASAP. > As for the implementation, I will start a thread in .i18n. <news://news.mozilla.org/3A1930A8.B8F167E9@bucksch.org>

Reassign to tao.

Hi, Erik: What do you think of this feature? IMO, we can achieve this by merging tables from various bundles. Comments?

Maybe this could be done using something like printf's numbered arguments. E.g. "Welcome to %1$s! Today is %2$s." What is the rest of the product doing for this type of thing?

> Maybe this could be done using something like printf's numbered arguments. > E.g. "Welcome to %1$s! Today is %2$s." Do you propose this as generic function or app-specific code? This bug is about the former: It is not reasonable to add replacement code for each and every usage of the product name. I want to be able to write something like hellomsg=Hello, welcome to %appsuitename%! and the app (e.g. Navigator or Messenger) just asks for "hellomsg", without doing any replacement itself, and gets back e.g. "Hello, welcome to Mozilla!". I.e., as a localizer, I want to be able to insert the placeholders anywhere in the properties file, and it should work, without modification of any code. > What is the rest of the product doing for this type of thing? You mean, what do we do today, if we need the appname in a string bundle? We create custom replacements. E.g. for the profilemanager, there is something like convertquestion=Do you want to convert your 4.x profile into a %1 profile? and the profilemanager then goes and uses printf to replace "%1" with the app name (which it got from another string bundle). Obviously, this does not scale: Adding such codoe in 70+ places is not reasonable.

Compare bug 80838. Dunno, why we have so different numbers (I found 70 instances in .properties files, Gerv found only 5 files) - Did I include DTD files in my counting or did the locales improve so much in the meantime? Note that this bug is not yet fixed: We hardcode the %brand -> Mozilla replacement for each instance, and need to do the same for each new one. There should be a generic mechanism.

One way to fix this bug might be to abolish .properties files altogether, and have the string bundle code read .dtd format files instead. There's already a fair bit of duplication between the two sorts. This would mean that DTDs would have to be able to #include each other (which they should have been able to do from the start, IMO). This would have the advantage that all the chrome would not have to include multiple ones in the SYSTEM declaration. If you want to do dynamic replacement in a DTD (as you can currently do in a properties file), all we do is define a set of special entities, e.g. &param1; &param2;... which, when you called StringBundle.FormatStringFromName() would get replaced with the passed parameters, rather than searched for in "parent" DTDs. Or, if this broke the entities mechanism, we could just have a convention to use some other strings. It wouldn't matter. Someone once told me why this wasn't possible... does anyone know? Gerv

Seems like no real progress has occured so far - how urgent is the need for having this implemented?

> Obviously, this does not scale: Adding such codoe in 70+ places is not > reasonable. Seems like just that has been done. Most of the instances of brand names are fixed now, I think. I'll have to look into it. I don't think that this is urgent anymore, given the approach that has been taken.

OK, sounds fair :-) I'll take this one and target it to the 1.3 release. Let's try to resolve it by then.

reassigning

I think the best way to do this would be to modify nsPersistentProperties::Load(...) to take an extra nsPersistentProperties &replacementProperties argument that can be null, and then when setting its internal property it would lookup any %replaceme% in the stream and replace it with $replaceme from the replacementProperties. When we first start up the nsStringBundleService it will create a new singleton nsPersistentProperties from "resource://gre/res/brand.properties" that it will supply to all new nsStringBundle loads. Hm.. thoughts?

Filter on "Nobody_NScomTLD_20080620"