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.
Related
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.
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'm developing a website that will be available in different languages. It is a LAMP (Linux, Apache, MySQL, PHP) setup, and it makes use of Smarty, mostly for the template engine.
The way we currently translate is by a self-written smarty plugin, which will recognize certain tags in the HTML files, and will find the corresponding tag in an earlier defined language file.
The HTML could look as follows:
<p>Hi, welcome to $#gamedesc;!</p>
And the language file could look like this:
gamedesc:Poing 2009$;
welcome:this is another tag$;
Which would then output
<p>Hi, welcome to Poing 2009!</p>
This system is very basic, but it is pretty hard to control, if I f.e. would like to keep track of what has been translated so far, or give certain users the rights to translate only certain tags.
I've been looking at some alternative ways to approach this, by either replacing the text-file with XML files which could store some extra meta-data, or by perhaps storing all the texts in the database, and retrieving it there.
My question is, what would be the best way to make this system both maintainable and perform well with high user-traffic? Are there perhaps any (lightweight) plugins I could take a look at?
You could give a shot at gettext. It is the way it is done in most C/C++ linux applications and it is an extension to PHP too. The idea is not very different from what you're already doing, but there are tools that ease the mantainance of translations (i.e. poedit).
For user rights to translations, gettext won't be of much help, I think you'll need to do it on your own or look at some frameworks if they have smarter solutions.
Maybe taking a look to gettext lib could help you get some hints http://php.net/manual/en/book.gettext.php hope it helps!
You will need to have a table in your database that you can use to store strings of text, each with an composite ID. the composite ID will be made up of language ID and text node ID.
You will need to give the user a chance to select a preferred language. You should make sure that you either have a default "this has not been translated" for every language you use, or a default language that your entire site can be vied in.
For every bit of text with in your web site, rather then store the text with in the page, you just assign it an ID.
When serving the page, look up the text node ID and preferred language ID and load that string of text, or the string for the default.
in our project, http://pkp.sfu.ca/ojs, we use XML files to store translation key-value pairs. Browse our code: http://github.com/pkp/pkp-lib/blob/master/classes/i18n/PKPLocale.inc.php
We use that class to read the XML files for each locale and in our code we use Locale::translate('locale.key.name');. Similar to gettext, but using an XML file for easier updating.
Looking around at web stuff today I came across this website: http://translateth.is/
It looks simple to use... copy paste in some javascript.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
OK I'll try again, sorry if it's too simple for you; we all have to start somewhere.
I need to use a webpage to specify the layout of the newspaper ie header, footer and news areas. This is produced by an HTML page which I have created [the one with check boxes and a create button].
A second web page is to add content to the various components; again, I have the HTML page with 3 sections for input to the header, body, and footer, each with a save button. The content then needs to be output.
The information is to be stored in a MySQL database, but I only need to use the web forms I have already created in HTML to design the layout and add content. The database is to store the layout and content information.
Changes to the database tables should dynamically reflect changes in the presentation page.
The database I have already created has 6 linked tables so far [layout, header, footer, local,national and international]. I also know the MySQL code to link with the database, but not how to code to POST information to the database from the web pages via php handling to the database or GET information from the database.
Can anyone help?
What I've learnt so far:
If you create a CMS you'll gain tons of programming experience.
If you want to build a news portal for a real client avoid [1] and use an existing CMS.
Although there are a number of frameworks and cms's systems that you could use. The php commands you are looking for to interact with the database you will find here.
http://ca2.php.net/manual/en/function.mysql-query.php
I hope this helps.
It sounds like you are reinventing the while, and all the problems that will come long with it. May I suggest you use an existing CMS? There are a myriad of options, but some of the more famous that come to mind include...
Plone
Joomla
Drupal
TYPO3
WordPress
There is even a wikipedia page on the subject: Web content management systems
I am actually working on a similar project. Dont use an existing CMS... most cms are overkill for something this basic... It also gives you more control over everything and it is a great way for a beginner to learn PHP and how to work with databases... One tool I have found helpful is FCKeditor... It allows the client to create a detailed layout just as if they were using Word but will return HTML to you...
Look into:
drupal
wordpress
As starting points. Good luck.
I have had success using WordPress in this fashion and would recommend it.
This post was helpful to me doing something similar:
http://blueprintds.com/2008/03/13/top-10-wordpress-cms-plugins/
As far as composing a page with separate content sections there are several approaches to take. Here are 2 common ones.
Approach 1: Make your theme's page or index template pull the content from separate "pages" or "posts". Choosing the section to include based on either categories you set on the "page" or "post" meant to display in that section or a customfield value indicating they are to be displayed in a section. I like this approach cause you get the nice html wysiwyg editor and versioning for the content.
Example of template:
html
<? php /*call main pagecontent*/ ?>
html
<?php /*call 2nd section of pagecontent (posts where category = '2nd section' limit 1)*/ ?>
more html
<?php /*call 3rd section of pagecontent (posts where category = '3rd section' limit 1)*/ ?>
etc
Approach 2: Use custom fields for the separate content sections for a single post (number of disadvantages here but it might be more straightforward to get something quickly.)
If more detail is desired for the above let me know.
I'm doing something similar for a client. Because of deadlines and budgets I gave up and have to use an existing CMS. That is my advice for you on this project. But I'm sure you will continue to develop this CMS either on the side or for the project anyway so what you'll need to do is in addition to connecting to the database you'll just create a function to call data from the correct table. You use SQL syntax within a PHP function and you'll say pull content FROM tablename WHERE table column=correct row for the page. The guy who linked to the PHP manual sent you to the right page.
I must say developing your own CMS is not a bad idea like a lot of people keep saying for a number of reasons.
1. You learn a lot in the process
2. Many cms's have tons of overkill.
3. While they're all overkill they miss one important feature and thats content blocks. Pages may need more than one editable content area. Wordpress and the like only allow you one main section of the page to edit. Sure, they have dynamic sidebars and menus but that's not what we're looking for. We need a CMS that allows you to edit a handful of different content areas of a page. I'm creating my own CMS for just this purpose. I'm having problems separating the code in such a way that I can just call functions within different page templates bu that's another story. Anyway, use the info in that PHP manual link. I think that's exactly what you're looking for. In the meantime don't give up on that CMS and don't listen to everyone who says that the world doesn't need yet another one. It does. A barebones one that pulls more than one main content area from a DB into a page. That's all. No plugins, no overkill. Just chunks of content. Maybe share your source code when you're done so some people can learn?