Closed Bug 248160 Opened 20 years ago Closed 17 years ago

[l10n] Add ability to translate chrome strings on the fly

Categories

(Camino Graveyard :: Translations, defect)

Product:
Camino Graveyard
Component:
Translations
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino2.0

People

(Reporter: stuart.morgan+bugzilla, Assigned: nick.kreeger)

References

Details

(Keywords: l12y)

Attachments

(1 file, 2 obsolete files)

Patch V1
19.46 KB, patch
mark
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review 
Since there's no OS X friendly way to localize the chrome strings (i.e.,
localizing requires re-packaging for one specific language), we should translate
chrome strings on the fly. Basically, for each chrome string we get, we should
do the following:
 - Parse it to see if it matches a known chrome string
 - Map the match to a key, and pass that key into NSLocalizableString
 - Substitute the returned string for the localizable part of the original string

While this is slightly fragile (requiring code changes when embed.jar strings
change), it's the only way to get complete localizations through the OS X
localization system.
Putting on the 0.9 list.
Status: NEW → ASSIGNED
Target Milestone: --- → Camino0.9
The current list of problem strings (from
http://forum.mozillaitalia.org/viewtopic.php?t=2281):

Status bar
   Resolving host @...
   Transferring data from @...
   Read @
   Connecting to @...
   Connected to @...
   Waiting for @...
   (Probably more from
http://lxr.mozilla.org/mozilla/source/netwerk/resources/locale/en-US/necko.properties#43)

Sheets
   @ could not be found. Please check the name and try again.
   [JavaScript Application]
   The operation timed out when attempting to contact @
   (Probably more from
http://lxr.mozilla.org/mozilla/source/docshell/resources/locale/en-US/appstrings.properties#37)

History
   Today
   Yesterday
   @ days ago
   Older than @ days 
*** Bug 248045 has been marked as a duplicate of this bug. ***
Giving my bugs back to pink.
Assignee: stuart.morgan → pinkerton
Status: ASSIGNED → NEW
Target Milestone: Camino0.9 → Camino1.0
*** Bug 268479 has been marked as a duplicate of this bug. ***
"dialog that asks confirmation when non HTTP and potentially harmful protocols
(disks: afp: etc.) are accessed through a link." from bug 268479
Assignee: pinkerton → qa-mozilla
Component: General → Translations
QA Contact: qa-mozilla
*** Bug 301960 has been marked as a duplicate of this bug. ***
*** Bug 301959 has been marked as a duplicate of this bug. ***
*** Bug 301958 has been marked as a duplicate of this bug. ***
Simon would you have time to look at this bug ?
Shouldn't the localizations be using localized embed.jar files? I don't think we
want on-the-fly translation, as it will be fragile in the face of string changes.
Several reasons why we should try to solve this bug:
1 - "there's no OS X friendly way to localize the chrome strings (i.e.,localizing requires re-packaging for 
one specific language)"
2 - point 1 breaks the habit of having a single multilingual package
3 - working separately on jar files forces localizator to use more tools than now we use: we haven't a 
lot of horsepower, so we need to keep things simple; we have done a lot of work in streamlining the 
l10n process in about 2 years
4 - in over a year nobody on the caminol10n mailing list has come up with a way to handle localized 
embed.jar files, so we... simply still don't know how to do it (ok, we can probably easily fix point 4...)
5 - Frailty is an issue we can handle, I think. We use to work on localizing nightlies before release, so if 
a string is broken, we'll probably catch it before release and we'll only have a few nightlies or alphas 
with issues.
First off, from an end-user pov, I think it's already silly that there's a
separate Camino MultiLang download necessary for an application that prides
itself as a well-integrated app that behaves according to Mac OS X norms.  From
a "technical" pov, I understand the issues; it's not the way the Mozilla
codebase is set up.  I'm not aware of other non-Moz multilingual Mac OS X apps
that act this way (even NeoOffice/J, based on OpenOffice.org which is set up in
a similar manner to Mozilla, manages to ship the 12 most complete--of
40--localizations in one app), though.

I would go so far as to argue that Camino 1.1 should ship as one app with all
available localizations and the separate MultiLang app discontinued.

As for frailty with string changes, how often have those strings changed?  Once
 a quarter on average (i.e., each of the three files touched once per quarter)?
 Maybe twice if someone didn't put the comma in the right place the first time?
 In that respect, they seem no different than Camino's Cocoa UI, where every
once in a while some new text UI is added, and occasionally the checkin comes
without requisite changes to Localizable.strings.  The L10N team localizes a
nightly or alpha, notices the missing/unlocalized strings, and files a bug;
eventually, the bug gets fixed.

Further, in the immediate future, we'll be releasing off of a shared "stable"
branch which 1) supposedly won't branch until major UI/string changes are
complete and 2) will have a L10N freeze at some point, anyway (but I'd assume
Gecko/Necko changes would fall under the first category and toolkit-app-specific
changes will make up the second).  If we're going to continue to more-or-less
track the toolkit timelines to leverage shared work and all that stuff for the
medium-/long-range future, I don't see how string volatility/fragility is a
"real" problem.

If it turns out that there's no way to engineer an on-the-fly translation system
for chrome, that's one thing, but I don't see any significant reasons offered
why we should not try to create such a solution.

P.S.  Apologies if this sounds like a smart-aleck rant; it's not meant to. :-)
(In reply to comment #14)
> First off, from an end-user pov, I think it's already silly that there's a
> separate Camino MultiLang download necessary for an application that prides

Yep, but size grows when adding more labguage, hence the english for evryone and
the multilanguage for people not willing to use English.

> a "technical" pov, I understand the issues; it's not the way the Mozilla
> codebase is set up.  I'm not aware of other non-Moz multilingual Mac OS X apps
> that act this way (even NeoOffice/J, based on OpenOffice.org which is set up 

It is, it's the way we embed .jar files and how the code using those files is
written.

 
> As for frailty with string changes, how often have those strings changed?  Once
>  a quarter on average (i.e., each of the three files touched once per quarter)?

Often, when a component gets changed (like the new Pref panes), many string
changes. On a release branch, there is not much change. On trunk it depends.

>  In that respect, they seem no different than Camino's Cocoa UI, where every
> once in a while some new text UI is added, and occasionally the checkin comes
> without requisite changes to Localizable.strings.  The L10N team localizes a
> nightly or alpha, notices the missing/unlocalized strings, and files a bug;
> eventually, the bug gets fixed.

> If it turns out that there's no way to engineer an on-the-fly translation system
> for chrome, that's one thing, but I don't see any significant reasons offered
> why we should not try to create such a solution.

I agree on that one. It's the easiest solution to have a more than one language
in one application.
(In reply to comment #15 and comment #14)

> Yep, but size grows when adding more labguage, hence the english for evryone and
> the multilanguage for people not willing to use English.

Add the fact that we (caminol10n) have been able only once (last time actually)
to synchronize with the English release. As I said, we're trying to keep the
l10ns update process simple in order to mantain this no-gap situation (along
with other reasons). Until we are not sure to match Camino's release schedule
everytime, I think it's good to have one official (English) package and an
evolving multilingual package. I really hope this goal can be met by 1.0 on.

> > As for frailty with string changes, how often have those strings changed?  Once
> >  a quarter on average (i.e., each of the three files touched once per quarter)?
> 
> Often, when a component gets changed (like the new Pref panes), many string
> changes. On a release branch, there is not much change. On trunk it depends.

Uhm, but here we're talking about the embed strings, that shouldn't involve
"native" portions like the pref panes. I guess changes there should have a small
bottleneck effect on development, especially once we have find out how to do it
for the existing strings.

Smokey Ardisson:
> >  In that respect, they seem no different than Camino's Cocoa UI, where every
> > once in a while some new text UI is added, and occasionally the checkin comes
> > without requisite changes to Localizable.strings.  The L10N team localizes a
> > nightly or alpha, notices the missing/unlocalized strings, and files a bug;
> > eventually, the bug gets fixed.

That's what I implied with my previous comment.
*** Bug 309854 has been marked as a duplicate of this bug. ***
Target Milestone: Camino1.0 → Camino1.1
*** Bug 327292 has been marked as a duplicate of this bug. ***
*** Bug 338740 has been marked as a duplicate of this bug. ***
Any new suggestions here?  How hard would it be to implement Stuart's method?  

Do we have access to the keys that define these strings in their .properties files, or are we just fed the matching string?
Keywords: l12y
QA Contact: qa-mozilla → translations
FYI, there's a very interesting post om caminol10n that sounds promising as a way of addressing part of this problem (the MathML strings live in Camino.app/Contents/MacOS/res/fonts/mathfont.properties, not embed.jar): http://mozdev.org/pipermail/caminol10n/2006-July/001664.html

It's not as elegant as turning them into localizable.strings, but it sounds like it can be done now.
(In reply to comment #23)
> FYI, there's a very interesting post om caminol10n that sounds promising as a
> way of addressing part of this problem (the MathML strings live in
> Camino.app/Contents/MacOS/res/fonts/mathfont.properties, not embed.jar):
> http://mozdev.org/pipermail/caminol10n/2006-July/001664.html
> 
> It's not as elegant as turning them into localizable.strings, but it sounds
> like it can be done now.
> 
This is was what I just wrote to the Camino l10n ML:

I'm thrilled with Igor's recipe, absolutely amazing, just tested the concept and despite a small crashing Camino issue (expected let me add) this seems the most promising way for banishing those "unlocalizable" strings we all complain for years.


Can this go official ?

--
Paulo
There might even be a way to automate Igor's procedure, since we can now specify our own content to be placed in embed.jar.

cl
I tried a trilingual embed.jar (English, French, and Igor's Russian), and my English Camino was suddenly giving me Russian chrome strings :-(

AFAICT, Gecko is using the chrome locale that's listed last in the installed-chrome.txt list, rather than matching the language of the UI or whatever.
(In reply to comment #26)

> AFAICT, Gecko is using the chrome locale that's listed last in the
> installed-chrome.txt list, rather than matching the language of the UI or
> whatever.

Do you think Gecko behaviour is fixable, or should we abandon the idea of localizing the jar and go back to the "on the fly" translation method?
While there might be workarounds that are able to "fix" this bug, they'll never be as ideal as the actual fix stated in comment 0.

I'm retargeting this bug for 1.2 as it would probably be a large code change.

Ludo, care to look at this?
Target Milestone: Camino1.1 → Camino1.2
I have an idea here. According to comment 23 it is possible to merge more localizations into the jars. So the remaining problem is how to make Camino change installed-chrome.txt to the current lang.

Well, maybe we can check at startup of Camino what the current locale is, and write that into installed-chrome.txt. This would have to be done before XPCOM is initialized and that file has been parsed.

Taking to investigate.  If someone has a (test-)localized embed.jar lying around, please attach it; that would make this easier for me.
Assignee: qa-mozilla → hwaara
(In reply to comment #29)
> I have an idea here. According to comment 23 it is possible to merge more
> localizations into the jars. So the remaining problem is how to make Camino
> change installed-chrome.txt to the current lang.
> 
> Well, maybe we can check at startup of Camino what the current locale is, and
> write that into installed-chrome.txt. This would have to be done before XPCOM
> is initialized and that file has been parsed.
> 
> Taking to investigate.  If someone has a (test-)localized embed.jar lying
> around, please attach it; that would make this easier for me.
> 

Embed.jar file pt-PT localization (Portugal) is available at http://pnascim1.planetaclix.pt/Camino/pt-PT_chrome.zip
Maybe this can be fixed in the same way that bug 331576 can('t right now).
The solution should be to set intl.locale.matchOS to true. This works for Firefox.  The thing is FireFox is not using embed.jar, but more files. 

Why do we use Embed.jar ? is embed.jar localized anywhere in the mozilla tree ? Or do we need to stop using embed.jar and start using the equivalent chrome files for necko/layout and other services Camino uses.
I bet this would get resolved if you move to xulrunner for your embedding story. At least partly.
(In reply to comment #33)
> I bet this would get resolved if you move to xulrunner for your embedding
> story. At least partly.

Since Camino is eventually going XULRunner (I know bsmedberg wants it to!), maybe we just have to wait?
Assignee: hwaara → qa-mozilla
Taking, I need a fix for Correo as well...
Status: NEW → ASSIGNED
Assignee: qa-mozilla → nick.kreeger
Status: ASSIGNED → NEW
Attached patch sttres WIP 1 (obsolete) — — Splinter Review 
Here is my WIP for the core patch that is needed in strres. This patch is needed because the call to |nsStringBundleService::Init()| is called before any of the init embedding code is fired up (where we register our own service).

Without this patch, an embedder can't override the |nsIStringBundleOverride|
 service with the Component manager.
Does any of the regular apps use the overrides?

Another question I had is on timing, would it suffice for the string bundle service to look for the overrides on first use?

Is there any chance for reference count mishaps if a string bundle already exists when a embedder comes up with the idea to call this routine twice, after changing the component associated with the contract ID?
> Does any of the regular apps use the overrides?

The only other class in the 1.8 tree that uses this interface is | nsStringBundleTextOverride|. It is designed to look for a file called custom-strings.txt. According to a comment in |nsStringBundleTextOverride::Init()|, it looks like if the class can't find the "custom-strings.txt" file, it bails out of service registration. I searched through the 1.8 branch and could not find a single instance of "custom-strings.txt". 

Also according to the nsIStringBundleOverride idl, this comment indicates that the interface is designed for embeddors (only?):

// to be implemented by an embeddor that wants to override some strings

> Another question I had is on timing, would it suffice for the string bundle
> service to look for the overrides on first use?

Thats definitely another option, my fear is that (I haven't validated this yet) some class calls the service and asks for a string before our embedding initialization takes place. 

> Is there any chance for reference count mishaps if a string bundle already
> exists when a embedder comes up with the idea to call this routine twice, after
> changing the component associated with the contract ID?

Yes, I need to addref and deref |mOverrideStrings|.
Attached patch Camino Patch V1 (obsolete) — — Splinter Review 
This patch introduces the Camino fix, adding a new interface that looks for a string to override in Localizable.strings and passing a gecko version (if one exists) back to the caller.
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Depends on: 384796
Attached patch Patch V1 — — Splinter Review 
Here is the Camino patch now that the intl/stress core patch has landed. This just introduces a service to the Component Manager that listens for a localized gecko string to override. When a call is made, we try and see if it is defined in the Camino Localizable.strings file. We only tell gecko not to use its string if we don't have a overridden version.
Attachment #252745 - Attachment is obsolete: true
Attachment #252845 - Attachment is obsolete: true
Attachment #278620 - Flags: review?(mark)
Attachment #278620 - Flags: review?(mark) → review+
Attachment #278620 - Flags: superreview?(mikepinkerton)
Maybe we want to prepend some string constant to the Gecko key value to reduce the possibility of conflict?  r+ either way, just tossing an idea out there.
Target Milestone: --- → Camino2.0
Comment on attachment 278620 [details] [diff] [review]
Patch V1

+class CHStringBundleOverride : public nsIStringBundleOverride

I'd like to see a class-level or file-level comment here on how this intercepts the gecko strings and how it fits into the whole process. 

sr=pink
Attachment #278620 - Flags: superreview?(mikepinkerton) → superreview+
Comment added to the file (inside the function call).

Checked into the trunk.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Filed bug 394105 on actually doing the stuff that will allow l10n to translate Cocoa .strings files at the end of the day (whatever that stuff may be) for Camino 2.0.
Summary: [l10n] Translate chrome strings on the fly → [l10n] Add ability to translate chrome strings on the fly
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: