Closed Bug 77207 Opened 24 years ago Closed 24 years ago

The future of View | Translate

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: gerv, Assigned: gerv)

References

Details

Attachments

(4 files)

parser-and-other changes to support text/xul as a synonym for application/vnd.mozilla.xul+xml
6.89 KB, patch
Details | Diff | Splinter Review
Patch to pref-ize translation engine details
2.85 KB, patch
Details | Diff | Splinter Review
Patch with sr-requested changes (no extra comments)
2.33 KB, patch
Details | Diff | Splinter Review
Patch to use vendor-neutral translation service
807 bytes, patch
hwaara
: review+
shaver
: superreview+
Details | Diff | Splinter Review
View | Translate leads to a Netscape-organised, Netscape-oriented service. And their XUL is broken. It needs to die. There is a patch attached to bug 76998 to disable it for 0.9; it should be removed completely for 0.9.1 or replaced with an interface to either Babelfish, the Google translation service or (perhaps ;-) a translation service of the user's choice (eventually.) But in the short term it must die. Gerv
QA Contact: sairuh → teruko
Changed QA Contact to ylong@netscape.com.
QA Contact: teruko → ylong
Bugscape bug 4615 cause by this. cc jaime.
Thanks for the input Gerv. Much appreciated! We agree that View | Translate is a valuable service to the end-user for the Netscape Commercial release, and that Mozilla can do what they want for their releases. Adding roberts and epoirier to cc: list
Adding tpringle to cc: list.
Let me preface this by saying that I'm all for Mozilla's individuality and the weakening of Mozilla-Netscape ties in the public's eyes. If Mozilla.org could have its own translation service, or if we could allow the user to specify their own so as not to support some commercial service, then I'm all for it. I think we need to base decisions on quality (which matters to users) more than on the desires of some to keep commercial services completely out of Mozilla (which most users couldn't care about). Altavista (Babelfish) and Google are as much commercial entities as Netscape, and it doesn't make any sense (in my mind) to replace a Netscape-branded service with one of those just for the sake of it; let's make an "all or nothing" decision regarding Mozilla's usage and/or endorsement of commercial services. This seems like another instance where we're bending over so far backwards that our decisions ultimately have a negative impact on users, all in the name of avoiding Netscape. That said, I would probably support a switch to Babelfish translation services because I consider them of a higher quality than those offered by Gist in Time. But it pains me when I see bugs asking to remove full features that users enjoy just because they were the result of some Netscape-stricken deal. Isn't user satisfaction the ultimate goal?
Blake: nobody is using this service now, because it's broken. And nobody is stepping up to fix their server (nor can anyone even be located who could do such a thing, sadly). So, for now, it has to die. I don't care who provides the translation service, though Google has been a helpful member of the Mozilla community, so I tend towards preferring them. It's way too late for us to say that we won't have anything to do with commercial organizations, even if we were to want to do so. But this feature is broken, it was put in the tree because of a private Netscape/Alis deal, and not because of a contribution from Alis to Mozilla, and nobody is stepping up to fix it. Whoever wants to contribute a _working_ version of this feature should come to Mozilla and offer it, in the open, and subject to Mozilla's review and community consultation practices. Until then, this code is broken and, apparently, unowned, and that yells "remove me!" to this hacker. I think that links to commercial/branded services within Mozilla should be controllable through visible prefs, though, rather than hard-coded into the application, which may mean that any such services need to pass the mpt-pref test. =) (And yes, I die a little each time I see the plugin downloader.)
My point is that two of the three reasons for axing this service in the original report are because it concerns Netscape. In any event, theoretically someone in Netscape cares about this, given that it affects their deal and their product...Jaime, do you know who this would be? Where are Google's translation services?
I didn't mean the bug to be so "it's Netscape so let's ditch it" (although clicking on a Mozilla feature to read all about "Netscape technologies" isn't very good. But shaver makes the points more eloquently than I. Gerv
I am the Netscape PM, who owns the Alis Gist-In-Time relationship, so I think I can be of some help here. First, I think we all agree, that translation from the browser is a good user benefit. Second, the feature is broken in a couple of ways: 1) JS issue Bugscape 3782 and 2) XUL syntax errors on the site. Alis, can most certianly fix the syntax errors, once they get some help on the changes that have been made (minor issue they can correct very quickly). I've left a voicemail and sent an email for them to do so. As for the JS error, we are gonna need Vishy's team to help with this one. I logged the bug in bugscape a while ago, but I it has not been addressed. Adding Vishy to cc: list. I think the real goal here is 1st to get the feature up-and-running again, then to log other bugs to address where View | Translate should point to for Mozilla. (Please Note: Most of the front-end service folks, like Babelfish and Google, are just that . . . front-ends to the actual libraries that power the translations. The problem here is that the front-end sites may go away because revenue concerns/issues - -> non-sustainable ad based revenue models).
Some more ways that this feature is broken: 3) It makes requests of cgi.netscape.com. Why? Surely you're not tracking what URLs people are translating? 4) Phrases in the resulting pages like "What is the Gist-In-Time™ feature in Netscape 6?" and "Suggest a favorite link for other Netscape 6 users". > The problem here is that the front-end sites may go away All the more reason for the translation provider to be configurable, and not hard-coded to Alis. And, IMO, if Alis want to be one of the options we ship with by default, they are going to need to provide a page with more Mozilla-friendly text. Their disclaimer is quite cool, though. Maybe throwing the doll out of the pram about the Netscape-centricity with such a short time to go before 0.9 is a bit harsh, but I think it's only fair to say that if a Mozillified version of Gist-In-Time doesn't appear reasonably soon (and before 0.9.1), then when this gets rewritten to support multiple vendors, Alis will not be one of those included by default. At least not in my patch. Gerv
Gerv - I like the concept and flexibility you are describing, because it allows the user to customize their experience, however i also agree that it is too close to M0.9 to be fidling with this now. Rather, we can get the partner to fix their pages (e.g. Their pages are in XUL, so they pick-up the Theme of the browser UI. Shows off the technology very nicely), and have Vishy's team fix or advise them on a workaorund for Bugscape 3782 (Navigator.js eorr). The one thing, I would add would be the ability for embedding clients to set a default translation service for business reasons. After that, if we allow the user to switch or choose from a selection of "best-of-breed" Translation services, I think that would be a nice thing to do for the user.
Eric - This needs to be fixed ASAP!
Severity: normal → major
Priority: -- → P1
Hi, My name is Eric Poirier and I work for Alis Technologies. I am the "banner-advertisement-ruined/evil-capitalist" who developped the AutoTranslate concept with the great help of Cindy Roberts from Netscape. We can usually be tracked-down through bugscape not bugzilla or through the email address in AutoTranslate support. The direct contact for support is Martin Proulx mproulx@alis.com Note that we were in bugzilla for a while before beeing kicked out for the sin of being "commercial people", but we would be glad to participate again and be named responsible of bugs filed against the feature. We are very proud to contribute to the Mozilla effort with a feature that we tried to make as seemlessly integrated into the browser as we can! That's the motivation for using XUL in our service!!! We want people to feel it's the browser that's multilingual and more powerful, not that we offer just any multilingual translation service. As for branding it to Mozilla, this could be considered. We are a living proof that XUL can be served-up dynamically from web servers to deliver a service to the Netscape and Mozilla community and... yes we try to follow-up with almost weekly changes in XUL syntax since close to 18 months now. Not to mention seasonal changes in MIME types! Just to show that it can be done, that it's used by tons of Mozilla users and we rely on XUL do this is a cool anyway. Now, talking seriously about the bug. We changed the XUL syntax slightly (button tag label="abcd" vs. value="abcd" ... both tags were added because they are mutually ignored by their respective mozilla versions) That means it's now compatible with 0.9 0.8 and 0.7 but, we still have a problem with your change in MIME type... Please make an alias to support the previous MIME type(s)! Otherwise, we need to work with separate instance of our HTTP servers with different MIME type settings or play with Apache MIME typemaps which are a pain. (3 days of work up to now) + redirections based ou Mozilla versions... It's a real pain, we will probably have it fixed by Wednesday next week in production, but it's really not clean. I think you should now start to look at backward compatibility when you change the XUL file formats, the browser is used by lots of people and more and more XUL files will be loaded dynamically from servers like we try to do here. Sincerely, text/x-xul-is-cool
Status: NEW → ASSIGNED
I have to say, I'm swayed. If a Mozilla-branded service could be provided, I think people would be pretty amenable to pointing Mozilla at it. As far as the real bug, yes, I think we _should_ support text/xul as an alias, and I'm sad that we don't. I _doubt_ we can do that for 0.9, unfortunately, but I will look into it and ask drivers@mozilla.org if they would take that sort of patch. We're getting _really_ close to the wire here. I'll see if I can hack something up tonight, to start that process. Eric: do you want to assign this bug to yourself? It sounds like you'd be the right person to help us figure out a good solution here, and I'm sure Blake won't mind having one fewer controversial bug on his list. =) (FWIW, I'd be happy to come meet and represent mozilla.org officially in a face-to-face discussion about this, if you think that would be helpful in moving forward. For once, my Canadian geography is convenient for my work on Mozilla!)
> Note that we were in bugzilla for a while before beeing kicked out for the sin > of being "commercial people" If you start being "Mozilla people" you are welcome back :-)) > Otherwise, we need to > work with separate instance of our HTTP servers with different MIME type > settings or play with Apache MIME typemaps which are a pain. Currently, in navigator.js, a translate request means we we request the URL: http://cgi.netscape.com/cgi-bin/translate.cgi?AlisUI=simple_frames/ns_home&AlisT argetURI=<uri> which, after evil Netscape tracking is done ;-), becomes: http://www.teletranslator.com:8080/?AlisUI=simple_frames/ns_home&AlisTargetURI=< uri> Surely the easy way to distinguish between old and new Mozilla versions is to change the part which reads "simple_frames/ns_home" to e.g. "simple_frames/mozilla_home". Then you can serve the right XUL with the right MIME type based on the URL, without needing any complicated sniffing. I would be very surprised if Apache makes it difficult to set up different MIME types based on the URL. Remember, Moz respects MIME type before extension, so you could set up the second MIME type to be the type for "foo.xul1" files and rename the XUL file to "foo.xul1". I would much prefer this solution to perpetuating the illegal text/xul MIME type. And yes, I was the person responsible for the change - it's my fault :-) > If a Mozilla-branded service could be provided, I > think people would be pretty amenable to pointing Mozilla at it. Absolutely. I have a multi-vendor translating service and UI working in my tree, although it needs a spot of polish. There's no reason why Alis should not be one of the options, and we'd be glad to have you. P.S. At the moment, I would lean towards make Google the default, because it does The Right Thing - i.e. it detects the source language of the page that's given, we give it the UI language of the browser and it just translates, without an intermediate step. So View | Translate gives you the page in your language immediately. It also rewrites the page URLs so they get translated too. So you can surf a "translated site." This is _cool_ :-) Can Alis do something like this? At the moment, Google only works for translating into English, so if Alis did it for more languages, it would rock. :-) Gerv
Gerv: I appreciate and even applaud (usually) your efforts to keep us standards-honest, but we (mozilla.org) have not done a good enough job deprecating text/xul to just be turning it off for 0.9. We need at least one more release with both supported, I think. (I felt this way about label/value, as well, but was swayed then by the increased effort in maintaining dual support. Supporting the pair of MIME types is relatively simple, though not as simple as I wish it was, so I think it's a good trade. We must be careful about how we treat our early adopters, like Alis, so that they stay adopters through the long haul.) I have a patch. It makes View->Translate work (though it doesn't seem to honour my Classic theme, and the advertising makes me wince, but it's no worse than all the cgi.netscape.com crap sprinkled through our UI). I'll attach it.
<turns palms upwards> Fair enough. It just seems to me that (if Alis were the only people bitten by this, and it really does seem that way) that my fix for their server would actually be easier and simpler than fixing Mozilla to support text/xul again. They are going to have to diverge the two versions at some point, after all, because text/xul will go away again... But you're the boss :-) Gerv
a= asa@mozilla.org for checkin to 0.9 Thanks Gerv and shaver.
I couldn't agree with Shaver's comments more. We have to very careful in how we support Content Developers who assumed the risk and who have early adopted. Staying on the standards compliance course is the goal, but we shouldn't look past the people we have supported and evangelized our efforts in the past. Thanks for all your help on this one Gerv. You really sparked some new ideas.
r=timeless on techincal merits, whomever sr='s should be aware of the other issues.
OK, so we'll check in shaver's patch for 0.9. No problem. However, this bug is still titled "The future of View | Translate", so here's my suggestion: I finish up the multi-vendor translation code (Gist-In-Time, Google, Babelfish so far) and UI well before 0.9.1. We hook that up to View | Translate with a single drop-down box pref in Prefs | Navigator | Languages to select the vendor (subject to confirmation from the UI folks.) I'll even promise to write it in such a way that lets you do the tracking redirect via cgi.netscape.com :-) I'd like to make it possible for additional translation engines to add themselves to this via an XPI, but that might not make it in for 0.9.1. We also back out text/xul before 0.9.1. This will be done as soon as Alis are ready and happy that they've sorted their server. We change the URL that Mozilla asks for from Alis in the way I outlined above, to make it really easy for the Alis folks to set up the two versions. Obviously, they'll only have to maintain one if XUL changes further. Does this make everyone happy? :-) Gerv
Almost there . . . does your code allow for a pref that alloows embedding partners to specify only one partners (i.e. some embedders may choose, for business reasons, to drive trafffic to one partner)? In short, is there a pref to remove options to add translation services, and/or delimit the number of offered options. Note: Sorry, I am a capitalist at heart, and some companies may need to make money to stay around. :-)
We're all capitalists here - that's why we have the MPL, not (or alongside) the GPL. My code allows that to a pretty high degree - merely set the default prefs to the values necessary for the partner, and remove the UI for changing them. The user could still change to another translation engine by editing prefs.js by hand, but (to a first approximation) no-one is going to do that. Also, if you have XPInstall enabled, I suspect it would be possible for another company to overwrite your prefs with theirs. But again, that would be hard to prevent. Is that OK? :-) Gerv
lol . . . que viva las capitalistas! que viva! sounds good to me. we'll know more, when folks first try to utilize the prefs. thanks again gerv. u r way ahead of me. rock on! :-)
sr=waterson on ``parser-and-other changes to support text/xul as a synonym for application/vnd.mozilla.xul+xml''. (Stick a thumb in the IETF's eye for me, shaver!)
Should we print a console message or javascript console warning when we see a deprecated/invalid mime type in 0.9? That would make it easier to catch the majority of the sites still using text/xul (rather than suddenly dropping support at 0.9.1.)
Passing off to Gerv, who's more involved in this than I am.
Assignee: blakeross → gervase.markham
Status: ASSIGNED → NEW
Gerv asked me what I thought of this bug. Well, bah. A translator is a tool which you can apply to the current page, or to the selected text in the current page. It takes you to a completely different URI from the one you're currently on. Now, some may find a translation feature very useful, and use it regularly; others (such as myself) will not use it at all. Other examples of such tools (and I realize I'm throwing a few bones to imagination-starved Mozilla distributors here) include: Anonymize Starts browsing, from the current URI, through Anonymizer.com's Web service. Validate Takes you to validator.w3.org's results for the current URI. (This tool would be of particular interest to those using the mozilla.org Mozilla distribution -- probably moreso than `Translate' would be. So why is it not there, when `Translate' is?) What's Related Shows you Alexa's page of links to other pages on the same topic. Encyclopedia Entry Takes you to Britannica.com's most relevant encyclopedia entry for the page you're on, judging by the text in the page -- or to the encyclopedia entry for the selected text. Stock Lookup Takes you to a page of financial facts, figures, and news about the company whose site you're currently on (or who you're reading a press release from). Find Citations Takes you to Google's list of pages which contain links to the page you're viewing. I don't believe any of these items belong in the `View' menu -- unlike the other items in the `View' menu, all these tools change the URI to one you've never been to before, rather than just changing the view of the current URI. Instead, I think they should be in the `Tools' menu (aka the `Tasks' menu). I don't believe that Mozilla should contain any of these by default; you should be able to collect them easily by clicking on a link on a site (e.g. Netscape.com) which provides these services. A simple `Tools' window, like the Bookmarks window, could allow you to re-order and remove the items in the menu. Under this scheme, which service `Translate' took you to would depend on which site you'd picked it up from (or which service your Mozilla distributor had chosen for you), rather than depending on the value of a popup menu in a panel in a branch in a prefs dialog a billion pixels away. As a first step towards this, I think `Translate' should be moved to the `Tasks' menu. (And while you're at it, you can add the missing ellipsis to the menu item.:-)
mpt: my attempt to place it on the Tasks menu would result in another horizontal divider (a group into which any and all of the tools you suggest would fit.) Knowing your dislike of these things, could you be more specific as to where on the Tasks menu you want this to go? As I see it, there are two reasons why Mozilla contains this by default. 1) Netscape struck the deal and put it in here instead of the commercial tree, because they thought it was useful and it made it easier for them 2) It shows off XUL rather nicely (when it works ;-) Now 2), it could be claimed, is a reason to have this above any of the other things you propose. Now, XPIs can execute Javascript, right? So any translation provider (e.g. Google) could provide an XPI to change the prefs relating to View | Translate from someone else's site to theirs. So, you are right - this needs no prefs UI. We'll give it to Alis first (as they got here, and their XUL is cool) and other providers can provide XPIs for themselves. I'll try and generalise the implementation to be able to take account of the quirks of other engines. <ramble>A sensible translation engine should be able to look at a page, get (or guess) the language, look at Mozilla's "Accept-Languages" header, get a selection of possible destination languages, and just Do It, without any intermediate UI... Gerv
First of all guys, I would like to thank you for solving so fast the backward compatibility issue of XUL MIME in today's daily build. Sébastien De Rauglaudre will contact you to plan on a separate URL pointing to the mozilla service. About the usefulness of translation... Our stats show that non-english speaking people use the feature 20 times more than english-speaking people. A non-english person will use the feature about 5 times a month. It would be much more than 5 times a month if people could find the feature in the first place and understand what it does. Don't think like english-speaking people here, think of japanese people who can't even read the 26 letters of the latin alphabet. 96% of Japanese people don't speak English... their entire web universe is narrowed to kanji and katakana. As my native language is French (that I learned at work), I can tell you that the web gets really small when you don't speak English, and if you are like my grand-mother, you will never find the View|Translate menu. Translation is not like Alexa, or What's related or any other service of that kind. If you can't read the damn page then the game is over. Gisting should be the Star-Trek feature of the browser... (don't use the word "translation", it's misleading in terms of expectations) Gisting lets you see the page in your own language. Is being able to understand the page in the first place basic enough? You shouldn't even have to look for the feature or to click on it to activate it. Here's my take on how it should work: User experience: 1- When you create your Mozilla profile, you enter the language that you can read. Yes that's the language prefs...(the rest will be accessible through gisting) 2- As a Japanese user, clicking on a link to an English page, you could see that page appear in Japanese right away (no clicking on View|Translate required). 3- You have clear sign in the UI that the browser automatically gisted the page. i.e. A simplified gisting toolbar appeared or a pop-up is querying you about gisting or a visible string in the UI says "Gisting mode" 4- When you surf that gisted page, gisting will continue as long as you don't reach a page in a language that you understand. Practical difficulties: - Detecting the language of web pages is pretty tough (Alis currently has server side AutoDetection based on 1- language and charset tags, 2- analysis of text contained in the page) - Time taken to gist a page - Confidentiality issues - User acceptance and understanding that the gisted page is not a page published by that site (people can get offended) - The translation engines can't be bundled with the browser (70 Mb per language pair and Alis is about to support close to 25 ones). The only viable solution is server-based processing. - Translation engines cost money... they also cost heavy CPU cycles (typically 7 seconds of CPU cycles on a pentium 500 MHz (orders of magnitude more costly in hardware than serving a standard web page) - Currently, server-side gisting is a proxway service (proxy-disguised as gateway for the browser) and it has the disadvantage of manipulating all the URL's that the user sees. Alis does a much better job a tit than all the other services as we don't even rewrite the URL's in HTML, we also rewrite dynamically the javascrit statements like location = "http://www.disney.com/" + ThePage; Cool isn't it? (= 6 months work) Next step is gisting the URL's and text contained in write() and writeln() statements, it's coming soon... There is a lot of stuff that I could say here, but I would like you to discuss the user experience described above. Thanks for your help again. MIME:text/vote-xul-for-president
Maybe we should take this to a newsgroup of some sort... > compatibility issue of XUL MIME in today's daily build. Sébastien De > Rauglaudre will contact you to plan on a separate URL pointing to the > mozilla service. Cool :-) I just sent a mail about that. > You shouldn't even have to look for the feature or to click on it to activate > it. Here's my take on how it should work: > 1- When you create your Mozilla profile, you enter the language that you can This is already there. Mozilla even tells the server what it is, in the Accept-Languages header. > 2- As a Japanese user, clicking on a link to an English page, you could > see that page appear in Japanese right away (no clicking on View|Translate > required). I don't agree. As you say, Gisting is not translation, and there are many Japanese people who read English well. If people can't find a top-level menu item, this is a user education issue. You mentioned privacy - I would also be wary about the browser passing URLs you visit through a random remote server without you specifically requesting it. > 4- When you surf that gisted page, gisting will continue as long as you don't > reach a page in a language that you understand. I certainly agree that the translation (this may be a deficient word, but it's also vendor-neutral) engine should replace the links in the page to links which pass the page through the translation engine. I think Google has the ideal user experience, as I said before :-) Once you View | Translate, you are then straight away (no intermediate "Choose languages" page) surfing translated until you click "original page". The advantage you guys have is that you do far more language pairs than they do. Gerv
In bug 65764 I suggested upping Mozilla/5.0 to Mozilla/5.1 in the user agent because of the major XUL differences between moz 0.6 and 1.0. This would make a lot more sense than just changing the URL translate points to as it doesn't help anyone else using remote XUL. As for text/xul I agree this needs to be out again by 0.9.1 if it's not then it needs to stay there permanently. Netscape 6 was released on a pre release of Mozilla so they have to take responsibility if some of their features don't work. If we leave it in for 0.9.1 (the recommended beta point) then mozilla will have more of an obligation to keep on supporting it.
text/xul, if the support did make it back in, was only on the 0.9 branch. It is not in current nightlies. This is why Alis really need to help me sort this out :-) 5.0 -> 5.1 is Another Bug(TM). Gerv
Adding aruner to cc: list. This code be an issue, if sites write to released Netscape 6 products, and we changed the code without compatibility.
Jaime or someone, So shaver's patch making text/xul an alias for application/vnd.mozilla.xul+xml is out now? It's difficult for me to measure the impact of this, but assuming that xul developers are the exception not the rule, then they sound like an evangelizable bunch and can be evangelized. So if I understand correctly, xul developers have to sniff for clients now. how bad is this really? any other $0.02? adding mgalli
> So shaver's patch making text/xul an alias for application/vnd.mozilla.xul+xml > is out now? According to my reading of LXR (which could be faulty) it was never in, not even on the 0.9 branch. It seems to have slipped through the net. But I don't have a 0.9 at hand to check. > So if I understand correctly, xul > developers have to sniff for clients now. how bad is this really? XUL developers have had to sniff for clients ever since we made backwardly-incompatible changes to the XUL syntax. That is not this bug. It's unfortunate fallout from Netscape's decision to release a product using code which was still subject to changes of this sort. This bug is about generalising the backend code for View | Translate and making it easy for Alis to support the two versions (one for Netscape 6, 6.01 and Mozilla up to 0.8.1, and one for Mozilla 0.9 and above, and derivatives.) Note that Alis will _not_ have to client sniff as we can change the URL we request from their site instead - as soon as they tell me what they would like the new one to be :-) Until this bug is fixed, View | Translate does not work properly in current nightlies. Gerv
Aruner - My comment is, that so long as Netscape plans to release products prior to M1.0, this may become a bigger issue, as "backwardly-incompatible changes to the XUL syntax" will actually get worse, right (i.e. It's a moving target)? Eric - Pls respond to Gervase comments.
We need the backend for this in before 0.9.1 leaves the platform - I'll attach a patch keeping the URL the same, then we can update that when we get a new URL merely by changing the pref. Gerv
r=timeless
CCing alecf for sr=, please :-). Gerv
ok, so sr=alecf on everything except the extra comments in all.js - we really shouldn't put many (or maybe any) comments in all.js, since it's one more file that gets read at startup we should probably create a page on gila which describes the "other" prefs, until we get a fancy UI which allows you to choose between translation providers...
awesome, thanks sr=alecf
OK, the back-end changes are checked in. When Alis decide the URL for the new-XUL version of their interface, they need to give it to me and I'll change the pref. It would be easiest to do this before the branch happens on Monday, but possible afterwards as well. Gerv
freeze happens Tuesday night at midnight, branch date has not yet been determined.
OK, the old Alis URL now works for everyone; so we're keeping it through into the branch. There is a new Moz URL, but it's not quite ready yet. We'll switch to that sometime in 0.9.2. For reference, the URL is: http://www.teletranslator.com:8120/?AlisUI=frames_ex/moz_home&alis_info=moz& AlisTargetURI= Gerv
This is probably not the right place to say this because the bug has changed from a "future of Translate" to specific implementation details... but I love the Alis translator, I use it constantly. As a car fan, and owner of what can be at best described as an oddity from Japan, much of the information I obtained about my car prior to purchase came from nissan.co.jp and similar Japan based sites. My ongoing boy-racer fascination with souped up wacko Skyline GT-Rs is fuelled by the webpages that this service allows me to read. The fact that Gist-in-time translates Japanese has been *invaluable*. If anyone ever considers replacing it, they should ensure that what they replace it with does nihongo!
I'm trying to use the translate option now. It doesn't seem to work, even after extensive waits.
I suggest to spilt this bug off into smaller bugs. This one is too long already. Translation provider quality: - Google only translates *to* english. Since most of the web is in english, I find the translation feature most useful for non.egnlish users. -> Google is not a good default option. - Babelfish has a horrible quality. - IBM Alphaworks demo produces quite good language. - Alis too Intermediate page: What I really dislike it that I have to confirm the From/To language. This adds one more pageload and click. What I would like is that I fire Translate menu item (or even optional button?), and I see the page translated into my mother language right away. Most providers allow that (just load a well-crafted get-query-URL), assuming that you know the dest ann target language. We do know the target language (Prefs|Nav|Languages, first choice), and we can hand it over as param in the URL. But we will have a very hard time to recognize the destination langauge. We need server-side support here. IBM Alphaworks demo allows that, IIRC. I don't know, if Alis' Gisting does. The translated page can offer options (e.g. via a toolbar like Alis does) to stop translating or choosing other languages. Menu item placement: I do think that translation is important enough to warrant a well-accessible option. But, we might be able to implement that with a JavaScript bookmark ("bookmarklets"). After all, all we do it take the current URL or selected text, do some trivial transformation and load the result as new URL. Lots of things like that have been done bookmarklets already. So, adding a new translation provider can be as easy as the provider giving a well-crafted <a href="javascript:..."> on a webpage and telling the visitor to bookmark the link. The menu item / prefs selector would have the advantage of visibility - the user doesn't have to find a good translation engine that additionally supports Mozilla. But then again, are we just doing marketing for translaltion providers?
epoirier: we have been waiting for some time for a non-Netscape-6-ified version of your translation UI. Do you have an ETA on this? Last I heard (a couple of months ago) it was "a week". The URL you gave me, which is quoted in this bug, still does not work. Gerv
Gerv - Eric is no longer with Alis Tehcnology. HE has moved onto another company. Pls try contacting Martin Proulux (MProulx@alis.com).
Adding Martin from Alis.
I have to second Eric Poirier's request for automatic translation. Gervase Markham wrote: >> 2- As a Japanese user, clicking on a link to an English page, you could >> see that page appear in Japanese right away (no clicking on View|Translate >> required). > >I don't agree. As you say, Gisting is not translation, and there are many >Japanese people who read English well. If people can't find a top-level menu >item, this is a user education issue. No, it's a problem of efficiency. If you do not speak English you would have to use this function a lot. (b/c most of the pages use that language) If people can read more than one language they can add more then one language to the prefered language list. The current solution is unusable: the only thing mozilla does is filling a URL in a form, then you have to click again and wait until the translation has proceded. Even worse the currently used service doenst translate URLs in the pages so that when one clicks on a URL he/she gets an untranslated page. The best solution would be: 1) automatically translate content when the language is not in the list of prefered languages if possible. If the original language is clearly not in the list but still in unclear: ask the user. or alternatively: promt the user: "The Page (Pagetitle) is Using German language. [View In German] [Translate with] [x] Translator A [x] Translator B [x] Translator C 2)offer tabs (like in multizilla) for the original version and the translated versions, this way you would be able to use more than one translator for one page 3)you should be able to set the way of how to form the URL for the translating service in preferences
This bug is hopefully no longer about removing Translate from the UI. In the fullness of time, it will move out of the View menu, into the Tools menu, when it exists. This bug is about getting Alis to provide a Mozilla-specific back end which doesn't say "Now you are using Netscape 6..." and other stuff. They were asked to do this several months ago, and I have had several emails a while ago telling me that they are doing it, but we have, as yet, seen no tangible results. I have also heard nothing back from my last few emails and bug prods. I like their service because it uses remote XUL but I will happily switch this over to Google in Mozilla builds if they keep ignoring me. Google has many of the automatic features you request which Alis' engine does not, and so this would improve the Mozilla user experience. Gerv
Depends on: 99988
> 1) automatically translate content when the language is not in the list of > prefered languages if possible. How do you know, if the user can read the page? Most pages don't advertize their language- Determining it is a very complicated heuristical process involving knowledge about languages. I see no way to do it in Mozilla. > 3)you should be able to set the way of how to form the URL for the translating > service in preferences If you mean prefs.js, then this is possible already, I think. If you mean the prefs UI, I don't think, that's a good idea. People who know how to decode and reconstruct URIs know how to edit backend-prefs. That's something the average user can't do. > This bug is about getting Alis to provide a Mozilla-specific back end > which doesn't say "Now you are using Netscape 6..." and other stuff. I filed bug 99988 for that. This bug has so many ideas that I think that we should file separate bugs for specific requests. > Google has many of > the automatic features you request which Alis' engine does not, and so this > would improve the Mozilla user experience. Gerv, as I said, Google is out, because it doesn't have the IMO most important feature: Translating from English to other langauges.
>How do you know, if the user can read the page? Most pages don't advertize >their language- Determining it is a very complicated heuristical process >involving knowledge about languages. I see no way to do it in Mozilla. well, you might be right for some languages; but for european languages this shouldnt be too difficult: -the encoding is detected as Western (this is already included and shows how difficult that is) -no umlauts/accents used --> English -umlauts -> German etc. also this should be backuped in the user interface, so that the user can change too a different language or to no translation. alternatively this assumtion could be made server site, but that would slow things down for the user. >> 3)you should be able to set the way of how to form the URL for the >> translating service in preferences >That's something the average user can't do. But you can offer a set of choices. I think it is alright that you have to edit prefs.js for the URIs. This way English speaking users could also choose google if they wish. >This bug has so many ideas that I think that we should file separate bugs for >specific requests. agreed, but IMHO there is too much that needs discussion. At least I am still in the brainstorming phase. well as we cant meet face to face a special newsgroup would be the best thing b/c more than User Interfaces is included here.
> -umlauts -> German etc. Wrong. Other langs use umlauts too. Also, it means that we have to dowload 2 pages - the original one (to determine the lang) and the translated one. > also this should be backuped in the user interface, so that the user can > change too a different language or to no translation. Yes. > But you can offer a set of choices. Yes, this was discussed above.
I've emailed Alis about this bug and 99988. Ben: for the default build of Mozilla, localised in English, Google is very much an option. Localisers are free to pick another translation engine which works with their language. Gerv
OK, Alis now have their vendor-neutral UI on line. The above patch patches Mozilla to use it. Bugs about lack of vendor-neutrality in this UI should probably be filed here and assigned to mproulx@alis.com , unless they have some other process they'd like to tell us about :-) Gerv
Comment on attachment 50732 [details] [diff] [review] Patch to use vendor-neutral translation service r=hwaara
Attachment #50732 - Flags: review+
Comment on attachment 50732 [details] [diff] [review] Patch to use vendor-neutral translation service sr=shaver
Attachment #50732 - Flags: superreview+
Checked in. jamiejr: you may wish to make sure that Netscape's commercial builds do not pick up this change. This would probably involve adding the pref with the old Netscape URL to ns.js or whatever the Netscape-specific pref file is, to override the Mozilla pref. Gerv
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Google has support for more language pairs than they let on (i.e. Japanese), *including* translation from English to other languages. It also has good automatic language-detection, so don't count them out of the running just yet.
Anyone is free to change their prefs to select a translation provider; and I expect many localisers may choose to do so also. At some point, someone might even write UI for this. But, given that Alis do cool remote XUL, and have kindly customised their interface to make it vendor-neutral, and have been good community members, it would be unfair to stop them being the default. Gerv
Fixed verified.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: