I have a dating site which is currently in English language.
As per client requirement he told me to convert the website in Polish language.
If I will create language file for the website, then I need to rework on whole project.
Is there any technique so that my website is automatically translated into Polish language when it is loading in browser. There also some hidden div's that will be displayed when a specific event occurs.
The website is created in php with smarty templating.
Please help me for this.
Thanks
If you want a custom solution, you're going to have to do some editing of your current code.
Option 1
Store all your strings in YAML files or within a database, or flat file, or however else you want them stored. The fact of the matter is that, as soon as your application loads, it'll query the database for the strings in your language (your url will have /en, /fr, /de etc at the end) and place those onto your page.
This means you'll have to code the retrieval of this data, and placement within your application.
Option 2
Use Google's "Auto Translate" as per Dainis' suggestion in the comments. This isn't as customisable, but means you don't have to do any reworking of your current code.
Option 3
Use Bing's translate API and manually request strings for the data you want translated on each request. Access to the Bing API is free for developers and has loads of free translations included - but this will be data intensive unless you cache the translations for future use.
With Option 3, you'll still have to code your own custom solution. So if you're on a tight deadline or you're just plain lazy, go with Option 2.
Related
They are some questions already about this on stackoverflow, but none is really clear about the 'best practice'.
For the content design, what are the options and what is the better option?
Some options I know are using folders: site.com/en/ and site.com/fr/ or redirects site.com/index.php?language=en
An even easier practice is using a new url: en.site.com and fr.site.com
But what if I want to keep site.com/index.php and nothing more ? What are my options for that?
For example, if you change the language on LinkedIn, there's nothing changing in the URL. How do they work there ?
update: in my case the website is a platform, using LAMP stack. Technical advice is also welcome (like how to store/link all the different language files)
You have some options, and each has its own advantages.
If you have a web app, which should not be indexed by search engines, then you are free to do whatever you want. You can keep a language setting in your Session and show strings in the chosen language. This will simplify URLs and management.
However, if you have a standard website which should go into Google, then your options are restricted. If you use the former approach, google will be confused and will index only one language, or, worse, make an ugly mix of the languages. Google does not keep sessions when indexing your page, so if you have two versions of the same page in two different languages, they need to have different URLs. And passing a language as a GET parameter each time is ugly, error prone, and not user friendly.
So you should either have languages as folders (eg. site.com/en/), which is the best options, or use subdomains. This can be a problem, however, because each subdomain is indexed as if it were a separate website, so things like pagerank and site reputation are split among the two.
Here are my recommendations based on multi-languages web sites experience
You can determine the language of the browser in Javascript (see this), which is a good start in having a language that likely fits the user demand
Use utf8 for encoding, everywhere (browser headers, programming, database). The only drawback I know of utf8 is that in some cases, the number of bytes it takes is bigger than another encoding matching more closely a given language (utf8 is opened to any). Big advantage, it covers any language, the ASCII part (bytes < 128) is the same as a western encoding (takes only one byte) ...
Store the user preferences (not in URL).
either in a cookie (+ : user does not have to be logged it on his computer to keep her prefs ; - : when user accesses the page from another computer, the cookie is not present and he/she has to reselect the pref).
or in a session (requires user login to deterime which user is currently using the site)
Regarding the site structure, if you don't store the user preferences, the common /us /fr /jp... solution has advantages: search engines robots will find all languages from root (the page display doesn't depend on user choice). Or you could load only a language dependent Javascript that displays the page immediately (after JS download) in the language of choice, without the need of a page reload / redirect.
You can tell Google what the parameters in the URL mean through Google's Webmaster Tools. So if you use a standard convention like index.php for the main page and a parameter like ?lang=fr for let's say French content in regard to SEO as long as it's a real translation. Likewise when Google.fr crawls the site you would present their users with the French version of the page based on their default setting in their browser. This will increase stickiness on the site and then increase the rank for the selected search terms in French. You can check their default language with this in PHP to make it less heavy on the user's end:
<?php
$lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2);
echo $lang;
?>
Then you would simply concatenate the language selected (as an overlay) to the end of the query string (if it's not the default), bypassing the need for storing a cookie. This should also help from a user experience standpoint. It's not as "pretty" but if people aren't typing it in, it's much more user friendly in that:
People can switch languages by changing the variable
People can provide a link to a user in another country and they can be presented with the page in their native language intuitively when PHP checks their language. "Do you want to see this content in French?"
The native language could in theory be translated on the fly with something like the Google Translate Widget or Google Chrome's built-in functionality.
Content is only served on one URI per page meaning you would not have to rewrite several redirects between versions in the event of stale content. As you're not likely translating into both languages at the same time.
From Wikipedia on Chrome:
As of February 2013, according to StatCounter, Google Chrome has a 37%
worldwide usage share of web browsers making it the most widely used
web browser in the world.
As for storing the files, you can make separate tables in the database for each language, enter in the content in the native language, then duplicate that content to the other language's table. Then you could translate that content live on screen if so desired, or allow someone access to your CMS who could translate the content. Both records would have the same ID in the database so the page would be served appropriately when the language was looked up.
Large corporate sites do the handling of the URLs in a couple of ways, they would show french content at http://www.some_website.fr/ and English content at http://www.some_website.com/. Sites like wikipedia use a subdns so http://fr.wikipedia.org/ and http://en.wikipedia.org.
HTML5 supports the lang='fr' approach to declaring content on screen.
I don't know what's your situation but, imho, you shouldn't use new urls.. it would only be a useless waste of resources (all kinds of resources).. If your website's client-side is javascript-based, you could use libraries like i18next, which gives you great support in localizations.. That's a valid alternative if you agree leaving the localization at you application's client-side.
For server-side localization in php, i wouldn't be of any help..
I was having a "discussion" with my manager today about the merits of using PHP includes and functions as a template to build websites more quickly and efficiently. He has been using Dreamweaver templates for years and sees it as really the best way to go. I would like to start using some different and more efficient methods for web creation, because we need to get through our projects faster. I would like to know in detail what would make Dreamweaver dwts better than using code to accomplish the same task, or vice versa.
His reasoning is:
When you change links on the dwt file, it changes links for every page made from that dwt.
Even if you move pages around in directories, it maintains links to images
Everyone in the company should do it one way, and this is the way he chose (there are two of us, with someone who's just started who needs to learn web design from the beginning, and he plans to teacher her the dwt method)
If you edit a site made with a dwt, you can't change anything in the template (it's grayed out), making it safer
If he's building sites with dwt, and I'm doing it with PHP includes, we can't edit each others' sites. It gets all over the place. When we have new employees in the future, it will get all crazy and people can't make changes to others' sites if they're out of the office.
I've been studying PHP these days, and am thrilled with how powerful it is for creating dynamic pages. The site in question which sparked this "discussion" is more or less static, so a dwt would work fine. However, I wanted to stretch my wings a bit, and the code was getting REALLY jumbled as the pages grew. So I chopped off the header, footer, and sidebar, and brought them in to all the pages with a php include, as well as dynamically assigned the title, meta data, and description for each page using variables echoed in the header.The reasons I like this better are:
It's cleaner. If every page contains all the data for the header and footer, as well as the extra tags Dreamweaver throws in there, then I have to sift through everything to find where I need to be.
It's safer. It's sort of like the above reason dwts are safe, except I do all my code editing in a text editor like Coda. So on occasion I have accidentally deleted a dwt-protected line of code because those rules only apply within dreamweaver. I can't chop off part of the header if I can't see it. Incidentally, this makes it easier to identify bugs.
It's modern. I look through source when I see great pages made by designers and design firms I admire. I've never seen dwt tags. I believe by using PHP to dynamically grab files and perform other tasks that keeps me from having to go through and change something on every page, life becomes easier, and keeps things streamlined and up-to-date with current web trends and standards.
It's simple. This should be at the top of the list. Like I said we have to train a new person in how to create for the web. Isn't it much better for her to learn a simple line of PHP and get an understanding for how the language works, rather than learn an entire piece of (not exactly user-friendly) software just for the purpose of keeping her work the exact same as everyone else's? On that note, I believe PHP is a powerful tool in a web designer's arsenal, and it would be a sin to prevent her from learning it for the sake of uniformity.
It's fast. Am I mistaken in my thought that a page build with header and footer includes loads faster than one big page with everything in it? Or does that just apply when the body is loaded dynamically with AJAX?
I did extensive searching on Google and Stack Overflow on this topic and this is the most relevant article I could find:
Why would one use Dreamweaver Templates over PHP or Javascript for templating?
The answer is helpful, but I would really like to understand in more detail why exactly we shouldn't switch to a new method if it's simpler and has more potential. My manager insists that "the result is the same, so if there isn't something that makes me say, 'oh wow that's amazing and much better!', then we should just stay how we are now."
(I do apologize for the length of this question, but the guidelines asked that I be as specific as possible.)
Like I said in comments, without knowing what exactly sites you are working with it's hard to tell which PHP features are most important to showcase. However, I can try and describe the most simple kind of sites I was dealing with, and where and how PHP came in handy. If you work with something more complicated, the need of programming language may only increase.
The simple website may have a few different pages with text and images. I'm assuming nothing interactive (i.e. no inquiry form), no large amount of structured data (i.e. no product catalog), only one design template which is used by every page with no differences whatsoever. Here's the typical structure:
One PHP file (index.php) for handling all sorts of php-ish stuff
One design file (template.php for example) for storing everything html-ish (including header, footer and more. Basically all html with placeholders for text and menu)
One CSS file for, well, the site CSS
Most of the texts are stored in database or (worst case) just txt files. Menu (navigation) is stored in database as well
Images folder with all the needed images
The key features here are:
Simplicity. You only have as many files and code as you really need to keep things organized and clear
Reusability. You can basically copy/paste your php code with little to no changes for a new similar website
No duplicates whatsoever.
Data and design separation. Wanna change texts, fix typos? You do it without as much as touching design (html) files. Wanna make a completely brand new design for your website? You can do it without even knowing what those texts are or where they are kept.
like deceze said, no lock-ins. Use whatever software you like. (Including Dreamweaver)
PHP is responsible for taking texts, menus, design and rendering them all into a web page. If website is in more than 1 language, PHP code choose the right texts for the language of visitors choice.
If texts are stored in database, you don't even need notepad and ftp. You just need, i.e., phpMyAdmin (stored in server) so you can connect directly to database and edit any text you like using only web browser; from anywhere in the world. (I am assuming no real CMS). If you need to add one more page, you connect to database using myAdmin and browser, enter the page name (for menu) in 1 or more languages, enter the text for new page (in 1 or more languages), done! new page created, name placed in the menu, all hyperlinks generated for you. If you need to remove a page, you connect to database and click delete. If you need to hide a page for a while (i.e. for proof reading before publishing), you connect to database and uncheck "published" box.
All this doesn't come with just using database ofcourse, you need to program these features with PHP. It may take about 1 - 3 hours depending on experience and the code is fully reusable for every similar website in the future. Basically you just copy/paste php file, copy/paste database tables, enter new text and menu into database, put placeholders into your html file and done! brand new site created.
Which immediately makes most of the reasoning for DWT irrelevant. You don't move files around because you have only one html file and no directories, you don't need grayed out template because texts/images (content) and template are not even in the same file, there's no such thing as changing links in dwt file because it's PHP that generates them on the fly (these are not real links to real html files but rather links with parameters to tell PHP which exactly page must be rendered.. because remember we have just 1 file). The bottom line is, comparing features of the two side by side is like comparing features of a sword vs machinegun. Sharpness and length of the blade concepts are meaningless in a case of machinegun; while lifetime sword user won't really get the meaning of velocity and caliber before he tries and uses machinegun. And yet, while you can't compare their features one by one, no one brings sword to a gunfight for a reason :)
As for #3, currently there are many more people working with PHP than DWT (in a case you will need more employees in the future, or if other people will need to work with your websites later, etc.) As for #5, you can edit PHP websites with Dreamweaver as fine as DWT websites.
That's just off the top of my head. I wrote this in my lunch break so I likely forgot or missed quite a few things. I hope you will get a proper answer with detailed DWT vs PHP comparison too.
You simply can't compare PHP vs. DWT.
PHP is a programming language, where templating is just one of it's numerous features, and DWT is just a silly proprietary system to build simple web pages.
there is actually nothing to compare.
I would say that using DWT templates over PHP do have some advantages.
It does not need any extra server-side process, like PHP to process the files at the server.
You can serve all files to the user as .html files rather than .php files, though I suspect that it is possible to hide the .php extension. Why should any user see anything other than .html?
You don't have to learn PHP syntax/programming. It is true that you can do more with PHP that plain .dwt files but for plain templating the .dwt files can be just as clean.
It is not true that .dwt files are a lock-in technology. The feature is also implemented by other web editors, e.g. Microsoft Expression Web.
I am building a web application in which the user may add a page, edit the layout, drag drop element, resize element, format the text, edit the element attribute etc.
In the page the user may include (retrieve) dynamic data, like maybe data from database, data generated by php code, etc.
I have played around with cakephp and jquery lately and tried to build this app. But I stumbled upon on how to appropriately display the php code. I tried to look into the cakephp core code and find about output buffering and tried to utilize output buffering to parse the php code and use regex to display it but it is more likely to reinvent the wheel if I write the parser my self
What I am asking is:
Ok, to be more simple and specific I just want to ask, how to save and load the page that was created by the user especially if the page contains php code. I just want to know is there any other method than write my own parser or maybe a library to parse a php code?
Ok that's all for now, does anyone have any idea how to implement it? Or maybe any page / website that could be useful to take some reference from? Maybe a sample code from which I can take some reference
Thanks
I'm not sure you'll find any good answer here about that.
Whoa I don't know where to start. I'll start by the number 3. You want widgets. Then that means you have to create widget class or objects that possesses a template or something that makes them drawable "well, kinda". If I were you it would be loaded from javascript and not really from php. Each widget would be in some way individual applications loaded in a div using javascript.
Point 2, You wanted widgets. When you add widgets to your page, you have to save some informations, like Position, Title, dimensions and so on. You may even save creation parameters. For exemple a ListWidget may be started with different ItemProvider. That way you don't have to write 1000 widgets but only one that shows different content. That said you have widgets, dimension and position. Now that lead us to point 1.
Point 1. Once you have your widgets, position and dimensions, you send the data you used to create them associated with the page to the server. That lead us two point 2 again.
Once you have saved a page. You can see it by retrieving all widgets with parameters and so on. That leaves you 2 options.
Generate Javascript that will recreate the saved widgets.
Generate Html will all the widgets.
Option 1 is simpler since option 2 won't bind html to javascript by itself. Solution 2 on the other hand is better since there is only 1 request to the server.
Oh and a last thing, You should set yourself some limits. That kind of thing can get very complicated and unfortunately not that great. See drupal for example. It does lots of cool stuff but as soon as you install lots of module. Drupal transform itself in some sort of memory eating monster. And almost all the time you don't really need that much of dynamic content. Fixed layouts will do work nice almost 99% of the time.
I'm also forced to say that but if you try to create an application that give users as much power as a scientist that could raise a 7 legged cat. I think you're going to play with really obscure forces!
Situation is simple. I'm starting to develop a website that should be localized based on visitor's origin IP address.
It's a PHP-MySQL stack. How do I go about the multilingual text content? I am thinking of having a language table in the database with the primary key as content identifier, another column for page identifier and separate columns for content in each language. Appropriate page content will be fetched as an array in the requested language and then displayed on the page.
Is this an efficient solution? I somewhat feel ridiculous to make database calls just for static content. I thought of having PHP definition files for each language and load the definitions during page load. But updating the definitions for each language are going to be like editing the files manually.
Has someone come out with an efficient solution for this kind of situation? Any input is much appreciated.
If the content is static like you say, why not use Gettext?
It's the standard regarding localization of content and has been discussed lots of times in StackOverflow.
So, currently I'm organizing my blog based on filename: To create a post I enter the name of the file. As opposed to storing the post in the database, I store them in PHP files. So each time I create a post, A new row in the table is created with the filename and a unique ID. To reference the post (e.g. for comments) I get the name of the current file, then search the entries table for a matching file name. The post ID of the comment matches the ID of that post.
Obviously this isn't the standard way of organizing a blog, but I do it this way for a few reasons:
Clean URL's (even cleaner than mod_rewrite can provide from what I've read)
I always have a hard copy of the post on my machine
Easier to remember the URL of a specific post (kind of a part of clean URL's)
Now I know that the standard way would be storing each post in the database. I know how to do this, but the clean URL's is the main problem. So now to my questions:
Is there anything WRONG with the way I'm doing it now, or could any problems arise from it in the future?
Can the same level of clean URL's that I can get now be achieved with mod_rewrite? If so, links are appreciated
I will be hosting this on a web host. Do only certain web-hosts provide access to the necessary files for mod_rewrite, or is it generally standard on all web-hosts?
Thanks so much guys!
P.S. To be clear, I don't plan on using a blogging engine.
As cletus said, this is similar to Movable Type. There's nothing inherently wrong with storing your data in files.
One thing that comes to mind is: how much are you storing in the files? Just the post content, or does each PHP file contain a copy of the entire design of the page as opposed to using a base template? How difficult would it be to change the design later on? This may or may not be a problem.
What exactly are you looking for in terms of clean URLs? Rewrite rules are quite powerful and flexible. By using mod_rewrite in conjunction with a main PHP file that answers all requests, you can pretty much have any URL format you want, including user-friendly URLs without obscure ID numbers or even file extensions.
Edit:
Here is how it would work with mod_rewrite and a main PHP file that processes requests:
Web server passes all requests (e.g., /my-post-title) to, say, index.php
index.php parses the request path ("my-post-title")
Look up "my-post-title" in the database's "slug" or "friendly name" (whatever you want to call it) column and locates the appropriate row that way
Retrieve the post from the database
Apply a template to the post data
Return the completed page to the client
This is essentially how systems like Drupal and WordPress work.
Also, regarding how Movable Type works, it's been a while since I've used it so I might be wrong, but I believe it stores all posts in the database. When you hit the publish button, it generates plain HTML files by pulling post data from the database and inserting it into a template. This is incredibly efficient when your site is under heavy load - there are no scripts running when a visitor opens up your website, and the server can keep up with heavy visitation when it only needs to serve up static files.
So obviously you've got a lot of options when figuring out how your solution should work. The one you proposed sounds fine, though you might want to give careful consideration to how you'll maintain a large number of posts in individual files, particularly if you want to change the design of the entire site later on. You might want to consider a templating engine like Smarty, and just store post data (no layout tags) in your individual files, for instance. Or just use some basic include() statements in your post files to suck in headers, footers, nav menus, etc.
What you're describing is kind of like how Movable Type works. The issues you'll need to cover are:
Syndication: RSS/Atom;
Sitemap: for Google;
Commenting; and
Tagging and filtering content.
It's not unreasonable not to use a database. If I were to do that I'd be using a templating engine like Smarty that does a better job of caching the results than PHP will out of the box.