It seems to me that the best solution would be to just tag everything with a language specification and give users an (overridable) default language option so that they don't have to choose every time.
Once this is done, then allow users options to only "see" stuff in certain languages. Sure, it means that some people will see things that other people don't, but that's close to the current situation where people can't read the non-English messages. The only difference here is they don't get the opportunity to feed it into Babelfish, but then they can just not have the option turned on if that bothers them.
The final part of the solution would be to display "languages spoken" on the profile pages, perhaps along with a skill level, so that people know to whom they should be speaking Spanish and to whom English, and so forth.
Optional extras include also allowing users to pick text directionality so that people can write in RTL scripts, and tagging in the HTML with lang and dir attributes so that, in the future, "clever" browsers can give the option to automagically translate portions of a document. (Could happen if more sites start specifying their languages.)
I have a feeling my grandparent poster wanted a machine-readable interface to the whole site, including comments, journals etc.
While that's great in theory, I know from experience that it just ends up inviting even more badly-written bots which mess up caches and hammer the site for ten minutes at a time because their authors are too incompetant to implement their own caching and stagger their requests.
When my mother went and bought an off-the-shelf PC from a big-name store I popped to my favorite little computer store and bought a cheap NIC to go in it. Imagine my surprise when the PC was delivered a few days later and it had an on-board network interface!
This prompted me to go into a few stores and poke around. It seems that the increasing popularity of DSL and cable alongside cheap home networking hardware have made on-board Ethernet standard issue.
(That redundant cheap NIC later went in my new router. It's nice to have some spare hardware lying around sometimes. :))
At my university there are jobs available for students in "Computing and Information Services", but they are limited to manning the helpdesk in a limited capacity, adding new paper/toner to printers and crimping network cables. A sufficiently-interested eight-year-old could do it!
It'd be much more convenient if they could just ship the CD with several compiled versions of the software. The data is (usually) common to all versions, so it's just the code which changes and id seem to work cross-platform throughout rather than porting at the end.
Still, my knackered old PC can't run it anyway, so I don't really know why I'm moaning!;)
For the sake of adding a bit more info to your explanation...
In later games using Duke's BUILD engine (written by then-teen-programmer Ken Silverman) the developers make the "room-over-room" illusion even better by simply doing two render passes. If you are in the upper part, then the first render pass will be the lower room, which since you are outside it doesn't include the ceiling, and then the second render pass renders the upper room using a null texture for the floor making it transparent. You had to line it all up quite carefully, but you could then get a room-above-room illusion that you can actually see, which was pretty neat.
Ken also later added support for voxel (volume pixel) objects, allowing true 3D objects to take the place of selected in-world sprites, although that implementation used low-res voxels so they looked a little blocky.
This made me think of the ZX Spectrum. In its BASIC interpreter, if a PRINT statement would cause the result of a previous PRINT statement to scroll offscreen, the prompt Scroll? would be displayed at the bottom of the screen. Pressing most keys would answer yes and let it continue to scroll, but if you press N the program would terminate with some silly error.
It made the "print hello over and over again" trivial BASIC example quite frustrating, since you'd have to explain to the learner why it was doing that. It was also annoying more often than it was useful. That's just because it was for the output of BASIC, though: in some situations (when triggered by an environment variable) automatic paging would be nice. However, the pager would have to notice when the input isn't long enough to fill the terminal and just pass through the output transparently, and it would also have to accept input for interactive programs.
The PAGER environment variable usually contains the path to a decent interactive paging tool. The difficulty, of course, is deciding which component gets to activate it. Having every program run the pager would be silly, but for the shell to activate it the output would have to be captured, and you'd have to have some way to turn the "automatically capture to less" thing off, and have it be off automatically if the listing is small.
I'm running Windows XP and from what I understand, there is no way I can remove Internet Explorer from my computer. Call me a space hog, but I don't like having un-used aps on my computer.
The guts of Internet Explorer are shared with Windows Explorer and other parts of Windows. It's only really iexplore.exe and a few DLLs which are specific to IE. By all means remove the Internet Explorer directory (in Program Files) but don't lose any sleep over the rest of it: any time you open a Windows Explorer window or the Add/Remove Programs control panel those leftover components will get a workout.
Yes. That is one example of a way you can take a file and find out what its type is or might be. After that, you know (with some degree of accuracy) what kind of file you have, which was my point. The type information isn't explicitly stored.
Also, PowerDVD has the worst interface of any software DVD player. Why try to mimick a real device with all of the limitations that go along with it?
I don't want a DVD *Player*, I want a set of DVD *Codecs* which can be plugged into my player of choice, where I play everything else. On Windows this means a few DirectShow plugins, but of course there's no standard media codec API for "GNU/Linux".
Stargate SG-1 also made a small joke out of the whole thing. In the first non-pilot episode they meet a bunch of people and Daniel Jackson has to figure out what they're speaking and translate, but obviously this couldn't work every episode, so in the next episode after that they meet some people who just speak English with an unusual accent, and they all say "You speak English?!" and shrug... and that was the last time it was ever mentioned.
As you say, it's all about suspension of disbelief. For these sci-fi stories to work, there must be an underlying "science" which we just accept without explanation. An example from Star Trek is the transporter technology. From this one unexplained technology which we must accept, a framework of other technologies can be built such as replicators and holodecks. What separates a good sci-fi (not hard Science Fiction, mind) show from a bad sci-fi show, in my opinion, is the ability to be creative within the confines of the basic premises of science we are introduced to, rather than just making up random gibberish as a get-out for a storyline which had no ending. The bad Trek episodes for me are the ones where they essentially punch a big "FIXME" button and the story ends.
The "universal translator" technology is another one of these, and by having it not work as we expect in some cases they destroy its role as a fundamental idea. It's even worse in Enterprise as they try to essentially "invent" it as part of the show, when there really is no explanation for how it can work.
The filename extension is just metadata, like the name, size and creation date. There's no real reason why it has to form part of the filename. That's just how DOS was designed.
Hiding the filename extension is Win95's (and its successors') way of emulating the Classic MacOS approach of storing the filetype in a separate metadata field. In DOS, it essentially was a separate metadata field (char filename[8], char type[3], if you like) but long filenames made that a bit hazy.
The point I'm riding at is that while storing it somewhere is good for usability, there's no good reason to put it in the filename. UNIX traditionally doesn't store this meta-data at all, and the user is left to just "know" what each file is. That's bad. MacOS's approach (storing the type as separate filesystem meta-data) is, I think, a good approach.
Of course, busting through all of your FUD, what they really mean is they can't just go in there and fix all of the bugs, because there are quite a few sites out there that depend on the bugs.
One thing Microsoft is fanatical about is backward compatibility. They had a whole team of people testing 16-bit apps to ensure they would run on Windows 95, and Win95 was full of little "shims" and other special cases to make applications which depend on Microsoft's old bugs and undocumented APIs continue to work.
From a purely idealistic point of view, I'd love it if MS just broke all of the sites which pander to IE's bugs, but I think we can all see that in practice that is not an option. Even Mozilla has lots of shims in it to emulate IE's bugs for the sake of backward-compatibility.
Think of $_ like "it". You can use it in everyday speech to get your point across in the minimum amount of words, or you can be verbose and spell everything out.
foreach (@page) { split(/\s/, $_); }
...should be read as "for each page, split it on the spaces." In this situation, in fact, the "it" is optional, but leaving it out makes things even more confusing unless you're writing something quick-and-dirty, which has no place in a full application:
y/abc/xyz/ foreach @name;
If you're writing something which is going to be used in the long term, it's wise to avoid the use of $_, not least because (by default) it's a global symbol and so you can get some weird bugs by one bit of code clobbering another's "it", like this:
Pick up the sword. Pick up the sheild. Give it to me.
The original poster vaguely dismissed this by claiming some "generic folder layout that has an abstraction to windows/unix/linux". However, even if we consider that unlikely, the user-specific part of the registry could be included on the removable device.
Windows is already set up to deal with remote registries in some configurations. It can't currently let you log into any arbitrary machine from removable media, but I can't see that as being incredibly hard aside from your encrypted data problem.
Of course, there is also the social issue that lots of people won't like the idea that their computer can play host to another user's entire environment, even if their own stuff is secure and untouched. I'm sure it would be thought of as coming into someone's house and somehow having all of the tables and chairs rearrange and the decor change to match your house, but having it return to the exact original state as you leave. It wouldn't really harm anyone, but most people would find it hard to deal with. People like to own and control things.
I dislike that approach because it suggests that every site must be "fixed" for the browser, rather than fixing the browser to work with the standards.
However, there are also more practical issues, such as that it can't be used for alpha-transparent background images, which are quite a common desire for designers using CSS; in CSS2, background images are the only way to introduce new images from the stylesheet.
In some limited circumstances it's possible to use alpha-transparency while gracefully degrading in IE.
For example, if you are using a solid-colour or almost-solid-colour partially-transparent image to achieve some kind of shading or tinting of the underlying background, you can do this and let IE display it as solid rather than transparent. People who only use IE will never know it was meant to be transparent and thus won't care.
The major trip-up here is that IE renders alpha-transparent PNG onto an unpredictable background colour. However, you can bypass this by adding a background colour chunk (bKGD, or something like that; it's been a while) specifying which solid colour you wish IE to render to. It will then render to that color and create the image with that color "showing through".
The limitations of IE's rendering are due to how IE was originally built to handle images. The image loaders hand the rendering component some kind of bitmap and a 1-bit transparency mask. This was a good choice at the time, but then alpha-transparent PNG came along, and since at the time GDI didn't have any mechanism to support alpha-transparency they just bodged it with the background color. At the time it didn't matter because no-one was using PNG anyway.
The new version of IE will hopefully support alpha-transparency since as of Windows 2000 GDI supports 32-bit images with (alpha,r,g,b) components, and there's already a PNG loader in the gdiplus library, so supporting it will be pretty trivial.
the prospect of asking a reader to change their browser window's width for every other page they visit is simply laughable in its utter disregard for the viewer's time and patience.
While I don't disagree with you, I thought I'd point out that technically, if every site adopted the approach being discussed, no resizing would be necessary because they'd all fit right at the same size!
With that said, see my parallel comment about user stylesheets and how they can help you help a website work for you.
Well, A4 paper is a bit wide for reading text comfortably at a sensible font size. Technically, of course, I should be fixing this my end by writing a print section to my user stylesheet, but Opera 6 won't let me apply the user stylesheet to printing, only temporarily to display, so for now I'm at the mercy of the site designers to get the print-friendly pages right.
I'm sure the user stylesheet situation in Firefox is better, although I do miss the ability to easily switch between user and document stylesheets; having to mix them together means that you can't do anything particularly interesting with the user stylesheet because all authors assume that all they have to override are Internet Explorer's defaults.
Talking of FireFox, you might have some luck with the following user stylesheet rule:
Unfortunately, by that time all of the content providers realised that by splitting the article over multiple pages they could show several different ads to the user as they read the article rather than just the one or two which got randomly picked when the first page loaded.
For sites I read often, I generally have my proxy server rewrite the URL magically to the print-friendly version for the sake of my sanity.
Talking of which: the print-friendly version of the original article is terrible. They've made it fixed width, but the fixed width they've chosen falls out of the size of the paper with my current browser settings. Site designers need to start using print-media CSS with max-width and some of the page-oriented properties to achieve their printer-friendly layout.
I also don't like reading overly-wide text. However, rather than expect every site author in the world to cater to my tastes, I just wrote a user stylesheet.
My user stylesheet allows me to click the document/user style toggle in Opera (I believe Mozilla/Firefox have similar functionality) and get the page under my terms, so long as the designer used sensible, semantic markup. In my case, I used max-width to stop the content getting too wide and set sensible font sizes, colors and so on.
I'm reading Slashdot that way right now, in conjunction with the more "light" template available in the user options. I find more and more sites I use work with it these days, so it's a lot more worthwhile to do this now than it was a few years ago.
Slashdot Mirror
It seems to me that the best solution would be to just tag everything with a language specification and give users an (overridable) default language option so that they don't have to choose every time.
Once this is done, then allow users options to only "see" stuff in certain languages. Sure, it means that some people will see things that other people don't, but that's close to the current situation where people can't read the non-English messages. The only difference here is they don't get the opportunity to feed it into Babelfish, but then they can just not have the option turned on if that bothers them.
The final part of the solution would be to display "languages spoken" on the profile pages, perhaps along with a skill level, so that people know to whom they should be speaking Spanish and to whom English, and so forth.
Optional extras include also allowing users to pick text directionality so that people can write in RTL scripts, and tagging in the HTML with lang and dir attributes so that, in the future, "clever" browsers can give the option to automagically translate portions of a document. (Could happen if more sites start specifying their languages.)
I have a feeling my grandparent poster wanted a machine-readable interface to the whole site, including comments, journals etc.
While that's great in theory, I know from experience that it just ends up inviting even more badly-written bots which mess up caches and hammer the site for ten minutes at a time because their authors are too incompetant to implement their own caching and stagger their requests.
When my mother went and bought an off-the-shelf PC from a big-name store I popped to my favorite little computer store and bought a cheap NIC to go in it. Imagine my surprise when the PC was delivered a few days later and it had an on-board network interface!
This prompted me to go into a few stores and poke around. It seems that the increasing popularity of DSL and cable alongside cheap home networking hardware have made on-board Ethernet standard issue.
(That redundant cheap NIC later went in my new router. It's nice to have some spare hardware lying around sometimes. :))
At my university there are jobs available for students in "Computing and Information Services", but they are limited to manning the helpdesk in a limited capacity, adding new paper/toner to printers and crimping network cables. A sufficiently-interested eight-year-old could do it!
It'd be much more convenient if they could just ship the CD with several compiled versions of the software. The data is (usually) common to all versions, so it's just the code which changes and id seem to work cross-platform throughout rather than porting at the end.
Still, my knackered old PC can't run it anyway, so I don't really know why I'm moaning! ;)
For the sake of adding a bit more info to your explanation...
In later games using Duke's BUILD engine (written by then-teen-programmer Ken Silverman) the developers make the "room-over-room" illusion even better by simply doing two render passes. If you are in the upper part, then the first render pass will be the lower room, which since you are outside it doesn't include the ceiling, and then the second render pass renders the upper room using a null texture for the floor making it transparent. You had to line it all up quite carefully, but you could then get a room-above-room illusion that you can actually see, which was pretty neat.
Ken also later added support for voxel (volume pixel) objects, allowing true 3D objects to take the place of selected in-world sprites, although that implementation used low-res voxels so they looked a little blocky.
This made me think of the ZX Spectrum. In its BASIC interpreter, if a PRINT statement would cause the result of a previous PRINT statement to scroll offscreen, the prompt Scroll? would be displayed at the bottom of the screen. Pressing most keys would answer yes and let it continue to scroll, but if you press N the program would terminate with some silly error.
It made the "print hello over and over again" trivial BASIC example quite frustrating, since you'd have to explain to the learner why it was doing that. It was also annoying more often than it was useful. That's just because it was for the output of BASIC, though: in some situations (when triggered by an environment variable) automatic paging would be nice. However, the pager would have to notice when the input isn't long enough to fill the terminal and just pass through the output transparently, and it would also have to accept input for interactive programs.
The PAGER environment variable usually contains the path to a decent interactive paging tool. The difficulty, of course, is deciding which component gets to activate it. Having every program run the pager would be silly, but for the shell to activate it the output would have to be captured, and you'd have to have some way to turn the "automatically capture to less" thing off, and have it be off automatically if the listing is small.
Not easy by a long shot.
The guts of Internet Explorer are shared with Windows Explorer and other parts of Windows. It's only really iexplore.exe and a few DLLs which are specific to IE. By all means remove the Internet Explorer directory (in Program Files) but don't lose any sleep over the rest of it: any time you open a Windows Explorer window or the Add/Remove Programs control panel those leftover components will get a workout.
Yes. That is one example of a way you can take a file and find out what its type is or might be. After that, you know (with some degree of accuracy) what kind of file you have, which was my point. The type information isn't explicitly stored.
Is there a "use native widgets instead of filling up RAM with useless bitmap resources" skin?
Also, PowerDVD has the worst interface of any software DVD player. Why try to mimick a real device with all of the limitations that go along with it?
I don't want a DVD *Player*, I want a set of DVD *Codecs* which can be plugged into my player of choice, where I play everything else. On Windows this means a few DirectShow plugins, but of course there's no standard media codec API for "GNU/Linux".
Stargate SG-1 also made a small joke out of the whole thing. In the first non-pilot episode they meet a bunch of people and Daniel Jackson has to figure out what they're speaking and translate, but obviously this couldn't work every episode, so in the next episode after that they meet some people who just speak English with an unusual accent, and they all say "You speak English?!" and shrug ... and that was the last time it was ever mentioned.
As you say, it's all about suspension of disbelief. For these sci-fi stories to work, there must be an underlying "science" which we just accept without explanation. An example from Star Trek is the transporter technology. From this one unexplained technology which we must accept, a framework of other technologies can be built such as replicators and holodecks. What separates a good sci-fi (not hard Science Fiction, mind) show from a bad sci-fi show, in my opinion, is the ability to be creative within the confines of the basic premises of science we are introduced to, rather than just making up random gibberish as a get-out for a storyline which had no ending. The bad Trek episodes for me are the ones where they essentially punch a big "FIXME" button and the story ends.
The "universal translator" technology is another one of these, and by having it not work as we expect in some cases they destroy its role as a fundamental idea. It's even worse in Enterprise as they try to essentially "invent" it as part of the show, when there really is no explanation for how it can work.
The filename extension is just metadata, like the name, size and creation date. There's no real reason why it has to form part of the filename. That's just how DOS was designed.
Hiding the filename extension is Win95's (and its successors') way of emulating the Classic MacOS approach of storing the filetype in a separate metadata field. In DOS, it essentially was a separate metadata field (char filename[8], char type[3], if you like) but long filenames made that a bit hazy.
The point I'm riding at is that while storing it somewhere is good for usability, there's no good reason to put it in the filename. UNIX traditionally doesn't store this meta-data at all, and the user is left to just "know" what each file is. That's bad. MacOS's approach (storing the type as separate filesystem meta-data) is, I think, a good approach.
Of course, busting through all of your FUD, what they really mean is they can't just go in there and fix all of the bugs, because there are quite a few sites out there that depend on the bugs.
One thing Microsoft is fanatical about is backward compatibility. They had a whole team of people testing 16-bit apps to ensure they would run on Windows 95, and Win95 was full of little "shims" and other special cases to make applications which depend on Microsoft's old bugs and undocumented APIs continue to work.
From a purely idealistic point of view, I'd love it if MS just broke all of the sites which pander to IE's bugs, but I think we can all see that in practice that is not an option. Even Mozilla has lots of shims in it to emulate IE's bugs for the sake of backward-compatibility.
Think of $_ like "it". You can use it in everyday speech to get your point across in the minimum amount of words, or you can be verbose and spell everything out.
...should be read as "for each page, split it on the spaces." In this situation, in fact, the "it" is optional, but leaving it out makes things even more confusing unless you're writing something quick-and-dirty, which has no place in a full application:
If you're writing something which is going to be used in the long term, it's wise to avoid the use of $_, not least because (by default) it's a global symbol and so you can get some weird bugs by one bit of code clobbering another's "it", like this:
The original poster vaguely dismissed this by claiming some "generic folder layout that has an abstraction to windows/unix/linux". However, even if we consider that unlikely, the user-specific part of the registry could be included on the removable device.
Windows is already set up to deal with remote registries in some configurations. It can't currently let you log into any arbitrary machine from removable media, but I can't see that as being incredibly hard aside from your encrypted data problem.
Of course, there is also the social issue that lots of people won't like the idea that their computer can play host to another user's entire environment, even if their own stuff is secure and untouched. I'm sure it would be thought of as coming into someone's house and somehow having all of the tables and chairs rearrange and the decor change to match your house, but having it return to the exact original state as you leave. It wouldn't really harm anyone, but most people would find it hard to deal with. People like to own and control things.
I dislike that approach because it suggests that every site must be "fixed" for the browser, rather than fixing the browser to work with the standards.
However, there are also more practical issues, such as that it can't be used for alpha-transparent background images, which are quite a common desire for designers using CSS; in CSS2, background images are the only way to introduce new images from the stylesheet.
What's your point?
In some limited circumstances it's possible to use alpha-transparency while gracefully degrading in IE.
For example, if you are using a solid-colour or almost-solid-colour partially-transparent image to achieve some kind of shading or tinting of the underlying background, you can do this and let IE display it as solid rather than transparent. People who only use IE will never know it was meant to be transparent and thus won't care.
The major trip-up here is that IE renders alpha-transparent PNG onto an unpredictable background colour. However, you can bypass this by adding a background colour chunk (bKGD, or something like that; it's been a while) specifying which solid colour you wish IE to render to. It will then render to that color and create the image with that color "showing through".
The limitations of IE's rendering are due to how IE was originally built to handle images. The image loaders hand the rendering component some kind of bitmap and a 1-bit transparency mask. This was a good choice at the time, but then alpha-transparent PNG came along, and since at the time GDI didn't have any mechanism to support alpha-transparency they just bodged it with the background color. At the time it didn't matter because no-one was using PNG anyway.
The new version of IE will hopefully support alpha-transparency since as of Windows 2000 GDI supports 32-bit images with (alpha,r,g,b) components, and there's already a PNG loader in the gdiplus library, so supporting it will be pretty trivial.
Indeed, "nick" can mean anything from shoplifting to just borrowing a pen:
While I don't disagree with you, I thought I'd point out that technically, if every site adopted the approach being discussed, no resizing would be necessary because they'd all fit right at the same size!
With that said, see my parallel comment about user stylesheets and how they can help you help a website work for you.
Well, A4 paper is a bit wide for reading text comfortably at a sensible font size. Technically, of course, I should be fixing this my end by writing a print section to my user stylesheet, but Opera 6 won't let me apply the user stylesheet to printing, only temporarily to display, so for now I'm at the mercy of the site designers to get the print-friendly pages right.
I'm sure the user stylesheet situation in Firefox is better, although I do miss the ability to easily switch between user and document stylesheets; having to mix them together means that you can't do anything particularly interesting with the user stylesheet because all authors assume that all they have to override are Internet Explorer's defaults.
Talking of FireFox, you might have some luck with the following user stylesheet rule:
Not tested, but it might work! ;)
Unfortunately, by that time all of the content providers realised that by splitting the article over multiple pages they could show several different ads to the user as they read the article rather than just the one or two which got randomly picked when the first page loaded.
For sites I read often, I generally have my proxy server rewrite the URL magically to the print-friendly version for the sake of my sanity.
Talking of which: the print-friendly version of the original article is terrible. They've made it fixed width, but the fixed width they've chosen falls out of the size of the paper with my current browser settings. Site designers need to start using print-media CSS with max-width and some of the page-oriented properties to achieve their printer-friendly layout.
I also don't like reading overly-wide text. However, rather than expect every site author in the world to cater to my tastes, I just wrote a user stylesheet.
My user stylesheet allows me to click the document/user style toggle in Opera (I believe Mozilla/Firefox have similar functionality) and get the page under my terms, so long as the designer used sensible, semantic markup. In my case, I used max-width to stop the content getting too wide and set sensible font sizes, colors and so on.
I'm reading Slashdot that way right now, in conjunction with the more "light" template available in the user options. I find more and more sites I use work with it these days, so it's a lot more worthwhile to do this now than it was a few years ago.