Currently the user agent string components are hard coded in mozilla/netwerk/base/src/nsIOService.cpp. We need a solution that will allow each platform to set their appropriate fields.

ifdefs?

ifdefs are the current "solution" which is broken. a) ifdef'ing platform specific code in network (xp code) isn't a good idea) b) most of these pieces aren't ifdefable (language, security level)

*** Bug 6090 has been marked as a duplicate of this bug. ***

There's nothing wrong with idfefs in this context. This is the perfect example of when you really do want them -- when the implementation has to be different on different platforms. Using them in an API would be bad, but I don't see any problem in the implementation.

As far as the platform peice of the UA is concerned; do we have #ifdef's for all thirty (or whatever the number is) of the platforms we run on?

Could we pick up those platform specific information from external files such as property files? XPCOM interface, nsIStringBundle (and nsIStringBundleService), can be used to resolve such problems. For such case, localization note needs to be provided to L10n group. Hardcoding shall be used as the last resort.

I see no problem with the following: #ifdef XP_MAC ... #elif defined(XP_WIN) ... others... #else #error No agent string for this platform -- developer please add one here. #endif If there are 30 different strings you need, I'd put this in a header file and put 30 different #defines in each part of the ifdef. I don't see why we need a more dynamic solution involving resource files, etc. but I could be wrong. Would someone ever want to take a Windows build and operate it with a different agent string? OS/2 maybe?

I don't have a strong feeling about the platform-specific portion of the user agent string. As long as the locale/language specific portion is localizable, i.e., not hardcoded. Unfortunately, it appears to be hardwired now: http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsIOService.cpp#62 You need to call nsILocale to get the current app/sys locale instead of hardcoding it as "en". This needs to be fixed. Add i18n folks to CC list.

Add comments to the status Whiteboard.

*** Bug 6297 has been marked as a duplicate of this bug. ***

tao, how do I get this nsILocale info. I can't find the nsILocale interface definition anywhere.

See sample code here: http://lxr.mozilla.org/mozilla/source/intl/strres/tests/StringBundleTest.cpp#190 & http://lxr.mozilla.org/mozilla/source/intl/strres/src/nsStringBundle.cpp#335

tao, what does the nsILocale api look like? I can't find it in lxr. What method would I call on it to the the lang designation (for example "en")?

Please refer to this method in nsStringBundle http://lxr.mozilla.org/mozilla/source/intl/strres/src/nsStringBundle.cpp#326 The interface, nsILocale, itself does not provide such method, you'll need to extract it in your code. BTW, you can the idlized interface declaration here: http://lxr.mozilla.org/mozilla/source/intl/locale/idl/nsILocale.idl

I'm not getting any response from Tague regarding how to have i18n set the language string. I'm assigning this to him for now. I'm also moving this to M10. We're sending legitimate UA right now, just not totally truthful.

i'll get you some sample code on monday (8/15/99). i've had other m9 things that needed to be taken care of.

I checked in a change to nsILocaleService today to add GetLocaleComponentForUserAgent. Use this API to get the appropriate locale component for the user-agent string. reassiging back to valeski@netscape.com. let me know if you need help hooking this up.

the language problem is solved, but how would you set a Netscape user agent vs. the Mozilla user agent? can this be configurable through some js pref file? I would like to avoid recompiling at all costs.

Adding lyecies@netscape.com to cc list.

PR_GetSystemInfo can provide the following strings based on the system we're on. Does anyone have a pointer to the old doc that jwz produced regarding UA string composition? I'm thinking it would be cool to use at least the raw SYSTEM string in the UA string. RELEASE: unix defers to uname() and OS2 to its equivelent. mac and win don't produce release strings. ARCHITECTURE: PowerPC mips x86 alpha sparc ppc etc... SYSNAME: "AIX" "BEOS" "BSDI" "DGUX" "FREEBSD" "HPUX" "IRIX" "LINUX" "MacOS" "NCR" "NEC" "NetBSD" "NEXTSTEP" "NTO" "OPENBSD" "OpenVMS" "OS2" "OSF" "QNX" "SINIX" "RHAPSODY" "SCO" "SOLARIS" "SONY" "SUNOS" "UnixWare" "WIN16" "WIN95" "WINNT"

I've whacked off the language portion of this bug (waiting for tree to open for checkin). Still mulling the system portion (anyone have any revelations?). NOTE: Currently the lang piece (on my machine here in the US) comes back as "en-US". Is this ok? It used to be "en".

Ok. I'm using PR_GetSystemInfo() to set the platform piece of the UA string. My guess is that this will break some cgis as the format has changed (all upper case now, and introduction of new platform strings), but this is the right thing to do and we'll give it a shot. NOTE: PR_GetSystemInfo is returning WIN95 even though I built on WINNT. Investigating... language and new platform code checked in 9/14/99 11:40am

I have no problem with the locale string comming back as en-US. It makes it easier to distinguish between other English clients (en-UK, etc.) Anyone else have a problem?

Shouldn't this be done for beta? Has nspr 3.5 changed anything here?

Srinivas fixed PR_GetSystemInfo() to return the name of the runtime OS as NSPR bug #15738. According to his comments on 10/20/99 06:26 in that bug report, his fix was checked into the tip of mozilla/nsprpub.

Run this in the location bar: javascript:alert(navigator.userAgent) I got "Mozilla/5.0 [en-US] (Windows_NT; I)". You might try other platforms under different locale. -tao

I checked some other platforms and locales. Below is my finding: Platform/Locale userAgent Windows NT4.0 Japanese Mozilla/5.0[ja_JP](Windows_NT; I) Windows 98 Japanese Mozilla/5.0[ja_JP](Windows_98; I) Windows 95 Traditional Chinese Mozilla/5.0[zh_TW](Windows_95; I) Red Hat 6.0 with Japanese locale Mozilla/5.0[x-user-defined] (Linux; I)

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

FYI the user-agent for Mac is inconsistent with 4.5: user-agent: Mozilla/5.0 [en-US] (MacOS; I) User-Agent: Mozilla/4.5 (Macintosh; I; PPC) this is going to break a number of sites

http://www.mozilla.org/build/user-agent-strings.html I just noticed valeski asking the jwz user agent string document.

*** Bug 20139 has been marked as a duplicate of this bug. ***

shaver is going to build a JS UA object that will "do the right thing" wrt these fields.

The UA service uses PR_GetSystemInfo (under the hood), so it should make this better. Checking the whole mess in early in M14.

FWIW, current progress has the UA string looking like: User-Agent: Mozilla/5.0m13 (X11; N; Linux 2.2.5-15ipsec; en-US) Gecko/ on my Linux box. Locale comes from the locale service, base platform from a default pref file, etc.

Sorry for my ignorance. Bt, what's the "base platform" you're referring to here? Is it the system info? In addition, which default pref file it is? Thanks.

The base platform is "X11", and will be "Macintosh" on the Mac, "Windows" on Win. Those settings come from the per-platform pref files: unix.js, winpref.js, macpref.js. The system info is "Linux 2.2.5-15ipsec", and it comes from the PR_SystemInfo call, which calls through to uname on Unix and does something similar on the other platforms. The "N" (no security) is from all.js, and I would expect it to be set to "I" or "U" by the installation of an https component.

somewhere in the system info we need to specify architecture (for example parsing scripts need to differenciate between Linux unix arch and Linux x86 arch). I don't think PR_GetSystemINfo() give us this. I was making a direct call to uname on unix to get it (per jwz's doc).

PR_GetSystemInfo gives it to us, and I just added it: User-Agent: Mozilla/5.0m13 (X11; N; Linux 2.2.5-15ipsec/x86; en-US) Gecko/

Since we are already getting some info from the *.js in composing the user agent string, may I propose that we store the language info in all.js? Localization group will need to localize this string for each localized build. I will post it to newsgroup for comments. Thanks

How is that better than just getting it from the locale service, as Tague requested long ago?

The locale info returned by the nsILocale is the system/application locale which indicates the l10n characteristics of the native OS. It does not reflect the client's localization characteristics which is to be revealed by the user agent string for statistical purpose.

OK, I'll make it back to "mozilla.useragent.locale". Thanks for the info.

*** Bug 23807 has been marked as a duplicate of this bug. ***

Shaver: Are you still working on this, or should it go back to Jud now?

need the user agent to stablize at beta1 so content developers can start to use it for content negociation. jud, take this bug back if your ready to work on it.

PDT+. Back to valeski

not so fast. shaver put a hell of a lot of work into this, and I'm not about to re-create it unless I get confirmation from him that he's ditched it. My last conversation with him was that he was right no the cusp of checking it in.

Hi, Jud: Any idea about Shaver's plan on this bug? We need to decide whether to evangelize the U-S string change in beta1. Thanks

The lang portion in the app comment is now (once I checkin) a pref ("mozilla.useragent.locale", en-US). we do not init this field from teh webshell init anymore. is this what you want tao?

Which JS file will contain this pref? And you will use this value to compose the U-A string? Thanks

all.js and yes. is this what you want?

Yes, that's what was decided. Will installer be able to access this value during Seamonkey install session? I am under the impression that the prefs value in JS could be accessed in a very earlier session.

I have no clue.

ok, platform piece is in. language is localizable via all.js "general.useragent.locale", en-US (the default).

setting tever as qa to verify

verified: NT 2000021408