I'm trying to figure out if there is any way of showing a translated version of a certain website, but keeping the functionality of that website.
Meaning, I do want to 'overlay' the language from the source language to the wanted language, but without modifying the source website. Is that even possible?
A good example was if I could use an iframe, but somehow control the data before it reaches the iframe so I could replace/translate the content.
(the idea here is not to copy/steal any content from anyone)
No.. if you want keep the functionalty. A multilanguage site requires db and code ad-hoc.
Rebuilding a website made for only 1 language to support many languages is a big pain
There are two big problems you are going to have to solve:
If you downloand the content on your server, translate, then display it - it will be impossible to "keeping the functionality" of the website. Since javascript is, of-course, excecuted on the client side, javascript powered events would still work. However any server-side processing (which is the real power ie: query db, upload, search, etc..) of a web application will be gone because the webpage was not loaded from its origional host.
Secondly, if you load the page into the iframe on the client's side you are going to have to deal with the same-domain origin policy. This means that websites/javascript can only manipulate/ajaxify stuff from the same domain as the parent window.
Overcoming both of these problems probably means inventing somesort of new technology and would be a huge time/manpower investment.
My serious answer is to just accept what google (or other translation services) have to offer.
Related
I am creating an application that will use Web Sockets for a notification system. Is it better to have the application in an iframe with the Web Sockets in the parent so there isn't a new connection every time a page is loaded? Or maybe it should re-connect?
What are your thoughts?
If anyone has any other way in PHP to get push like notifications without sending a AJAX request every 10 seconds then let me know.
Thanks.
This is one of the options you have described.
The problem with that option is that there wont be direct control over the content of that inner iframe, and you will need to implement push message window communication between parent of iframe, in order to be able to change iframe src attribute, in case someone will refresh parent page, and iframe should refresh to actual state, not initial page.
Second problem, there will be no SEO at all. So your page wont be crawlerable by search engine robots. If SEO is important for your application - then this is not an option.
In WebSockets, if you work with sessions, it is important to make session available for normal PHP script and WebSockets logic, in order to keep consistent access to data it self. PHP will make it not an easy task at all.
You might consider Long Pull technique as well, as it allows to open one AJAX request and then get responses back, and this request can last some time but will eventually close and have to be reopened on client-side.
Another option is to review actual application architecture, and think of single-page application. It have as well cons and pros.
Good thing about it, is UX will be much higher. Response times as well as you will load less content and data.
Pros are that it requires lots of development on front-end side in javascript. As well there is two major routes you can do single-page applications. Consistent and inconsistent. In first case you need to make sure that your back-end will server static html on refresh or just navigating to specific link, the same way as your single-page application would generate using java-script. Then it solves issues with SEO. While inconsistent approach, will just be purely on javascript (front-end), and will have issues with SEO.
WebSockets usually used with single-page applications, for example Facebook Chat is great example of such. Or Google Talk while you are in Gmail account.
They are not meant to be used with often refreshed pages, as Handshake process is a bit more heavy than normal HTTP request.
Good Day all,
I have an existing site built. I was wondering, how can my site update automatically when another website updates too? This essentially means that my existing site will obtain information like Cost, Description, images from the other site upon update.
I was pondering web services but the other site doesn't have it.
Please advise!
Thanks!
If the other site doesn't have an API, your only option is page scraping, i.e. downloading the HTML and parsing it to extract the info you want.
If they have a page structure that doesn't change often, this is generally reliable.
You'd probably want to use PHP's DomDocument to extract the info.
Generally, people don't like it because badly designed tools can tax their system resources, since generating a whole HTML page is more resource intensive than generating an API response.
Page scraping is fairly widespread, though some people discourage it. It may be disallowed by the TOU of a site, possibly having legal implications. Or, your target site may have no problem with it. There are of course large businesses built on page scraping (see 'Google').
Me and a colleague were discussing the best way to build a website last week. We both have different ideas about how to store content on the website. The way I have always approached this has been to store any sort of text or image link (not image file) on to a database. This way, if I needed to change a letter or a sentance I would just need to go on the database. I wouldn't have to touch the actual web page itself.
My colleague agreed with this to a point. He thinks that there are performance issues related to retrieving content from the database, especially if every character of content is coming from the database. When he builds a website, any content that won't be changed often (if at all) will be hard coded on to the page, and any content that would be changed or added regulary would come from the database.
I can't see the benefit of doing it like this, just from the perspective of everytime we make a change to an ASPX page we need to re-compile the site to upload it. So if a page has a misspelt "The" (so it'd be like "Teh") on one page, we have to change it on the page and then recompile the site (the whole site) and then upload it.
Likewise with my colleague, he thinks that if everything was to come from the database there would be performance issues with the site and the database, and that the overall loading speed of the web page to the browser would decrease.
What we were both left wondering was that if a website drew everything from the database (not HTML code as such, more like content for the headers, footers, links etc) would it slow down the website? And as well as this, if there is a performance issue, what would be better? A 100% database driven website with it's performance issues, or a website that contains hard coded content which would mean 10/20 minutes spent compiling and uploading a website just for the sake of a one word or letter change?
I'm interested to see if anyone else has heard of it, or if they have their own thoughts on this subject?
Cheers
Naturally it's a bit slower to retrieve information from a database rather than directly from the file system. But do you really care? If you design your application correctly then
a) you can implement caching so that the database is not hit for every page
b) the performance difference will be tiny anyway, particularly compared to the time to transmit the page from the server to the client
A 100% database approach opens up the potential for more flexibility and features in your application.
This is a classic case of putting caching / performance considerations before features / usability. Bottlenecks rarely occur where or when you expect them to - so focus on developing a powerful application and then implement caching later - when it's needed and where it's needed.
I'm not suggesting storing templates as static files is a bad idea - just that performance shouldn't be your primary driver in making these assessments. Static templates may be more secure or easier to edit using your development tools for example.
Hardcode the strings in the code (unless you plan to support multiple languages).
It is not worth the
extra code required for maintaining the strings
the added complexity
and possibly performance penalty
Would you extract the string "Cancel" from a button?
If so, would you be using the same string on multiple cancel buttons? Or one for each?
IF you decided to rename one button to "Cancel registration", how do you identify which "Cancel" to update in the database? You would be forced to set up a working process around how to deal with this, and in my opinion it's just not worth it.
For the following pretty straightforward task: query a list of products from a DB and present it on a webpage,
consider 2 setups:
Setup1: PHP script queries. All content is built on the server and the entire page is served back to the client.
Setup2: Static HTML "page skeleton" requesting content using AJAX. Received content is parsed on the client side using Javascript and rendered using innerHTML or similar.
Of course the second setup only makes sense when you have pages, categories and tags for the client user to choose from.
I need to compare these two, at least by means of:
time it will take content to be served
user experience (setup1 is delivered as a whole, setup2 is delivered in "two parts")
scalability - how do the setups compare when I have 100,000 queries daily
Any thoughts on the issue will be much appreciated.
You may find the following question helpful: Smarty Vs. Javascript/AJAX
I brought up a few points in my answer to that question:
You should use server-side scripts to show any data that is known at the moment the page is loaded. In this case, you know the list of products should be displayed. The fact that a question's answers should be shown is known at page load.
You should only use AJAX calls to load dynamic data that is not known at the moment the page is loaded. For example, when you click the "comments" link under a question or answer on Stack Overflow. The fact that you want to view a particular question's comments is not known at page load.
Javascript should not be required to access core functionality of your site.
You should gracefully degrade functionality when Javascript is disabled. For example, Stack Overflow works just fine with Javascript disabled. You don't have access to real-time Markdown previews or dynamic badge notices, but the core functionality is still intact.
A single HTTP request to a server-generated page will load significantly faster than a request to load a page that makes five or six additional AJAX calls, especially on high latency connections (like cellular networks). See Yahoo's Best Practices for Speeding Up Your Website.
You should think of Javascript as a bonus feature that might not be enabled, not as something that should be used to construct critical pieces of your website. There are exceptions to this rule. If you want to do some sort of pagination in which you click a "next page" button and only the product list changes, AJAX might be the right choice. You should, however, make sure users without Javascript are not excluded from viewing the entire list.
There's nothing more frustrating than when a page can't be accessed because the web developer didn't obey the KISS principle. As an example, take Friendly's Restaurants. I wanted to check out their menu while I was at the mall, so I loaded their website on my iPhone, only to find out that you literally can't get any meaningful information about the restaurant without Flash. It's nice to have fancy menus with swooshing desserts flying everywhere, but in the end, I just wanted to see the items on their menu. I couldn't do that because they required Flash. Graceful degradation in service would have been helpful in that case.
Some things on the web can't be done effectively without Javascript. Displaying a list of products is not one of them. If you are still unsure, look at how other popular websites do things. I think you'll find most of the successful, well-engineered websites follow the guidelines listed above.
AJAX is probably better choice when only a small part of the page changes.
I would recommend starting with the server side version and then building AJAX on top of that. This way you will get also a version of your site that works without javascript, which you probably need anyway if you care about being indexed in search engines.
But first concentrate on creating a page that just works - you can always optimize it later.
Performance on the client has many factors. What is running at the time, what browser, what the content is, what the CSS of the page is, how full is the browser's cache, what plug-ins are installed, what is happening on the network, etc. Just remember that when you are playing with the numbers.
Unless the implementation sucks, AJAX should win hands down. Among the benefits are:
parallelism due to parallel requests on the client side (i.e. you can use multiple server CPU cores to serve parts of one served web page, that can't be done easily using PHP)
refreshing only small parts of the page is faster (less data to transfer, generate ...)
it scales much better since the server has less work to do (esp. if you can offload some of the processing needed for generating html to the client instead of just delivering it)
Dynamic pages like http://www.startpagina.nl/ have been doing this successfully since way before the recent AJAX fad (1 static file delivered, all customization done on the client side - last time I checked anyway).
Of course you can screw things up with either method so that it becomes slower than the other.
I'll try to keep this short and simple.
I haven't begun writing the code for this project yet, but I'm trying to work out the pre-coding logistics as of right now.
What I am looking to do, is create a method of sending data from one/any site, to another remote server, which would generate a response for the user requesting the data be sent.
Specifically, a web designer should be able to take a snippet of code I would have available on my website, implement it into their own page(s), and when a user browses their page(s), my service would be available.
A specific example, a web designer with a website (helloworld.com) could implement my code into their page (helloworld.com/index.html). When a user is viewing the page (/index.html), the user hovers the mouse over a text word (lemonade) for a couple seconds, a small dialog box pops up beside it, providing the user with some options specific to the text (example of an option would be "Define 'lemonade' at Dictionary.com") that if selected, would be processed at, and a response would be returned from my remote server (myremoteserver.com)
Obviously, I would want the code that designers would be using to be as lightweight and standalone as possible. Any ideas as to how I could execute this? Resources I should study, and methods I could implement?
Please do not create another one of those services that annoyingly double-underlines words in web site content and then pops up a ugly, slow-to-load ad over the content if I accidentally mouse over the word. Because that sounds like what you're doing.
If you're going to do it anyway, then what the "remote server" will be will probably actually be a bit of client-side JavaScript, in which case JSON is probably your best bet. XML could also work, but even when JavaScript isn't on the other side, I rather like JSON as a serialization technique due to its compactness and readability.
I think you are talking about a hyperlink.
The part that has you confused is the level of interactivity you want on the client site. Whatever sort of neat UI interface you want to wrap around the link will probably be done in javascript and need to be supplied to that site. The core of what you're asking for
text ... that if selected, would be processed at, and a response would be returned from my remote server (myremoteserver.com)
is just a hyperlink.
There's probably more to it than that though. Explain and we'll try to help.
I'll elaborate and furthermore explain that I am not making one of those 'annoying' webservices that turns resourceful information into a clunky billboard. I intend on making a low graphic (16x16 icons at most per menu option) resource linking tool that can be used to connect resources on the local server to other resources, whether local or remote.
This data would be accessed by sending a request to my webserver and returning a response in a popup box (this response would be based on the query of course) The response would be displayed in a brief menu of options, for example Wikipedia entries, links to torrent searches on popular engines, etc.
It won't be inhibitive of selecting, scrolling, clicking predefined hyperlinks, or anything, as you would need to hover the text for a few seconds.
I'm just looking for resources that would be helpful in designing such a service.