Website templating pros and cons

Server side rendering is definitely the way to go. As to whether you should use templating - that is a very open ended question is dependent entirely on the site you are building and how it will work.

Most templating frameworks wrap content output in a function or class - the template is just a means to make the HTML look cleaner when you have to do things like variable insertion, looped outputs etc.

HI,

Thanks for the comments - I have experience in back-end so that makes things 100% easier.

Every new project i always look at new ways to do things and see if there is something out there that works better - in this case i think i got it covered.

Back to localization.
I have been looking at gettext -> is there  a better solution for an app

Seems like there will be one larger conversion page with  

#Comment #1
#english text to be converted
#convertered text


#Comment #2
#english text to be converted
#convertered text

so on  for the entire site?


What i have essentially done is created two tables (one internal and one for the user)

The internal table contains three columns that are for the app to use such as

term    |     description    |   acceptableValues

bithday        |      The birthday of the user | [0-100]
gender.......


The table contains predefined data that the user an update/ add to their details

The user internal would be

id               | user_id       | term   | value

1              |  1                  | birthday| 20
...

Essentially i would want the description and term on the internal table converted but do not care about the users input

Gettext certain performs well, but that's because it's a compiled extension that focuses on this functionality. It needs to be included as an extension in your build, and you need to take some additional steps to get it set up.

Personally, I would just go with custom code for doing this. Set up a database table that contains your Key/Language/Value rows, and populate it with your various strings:

Key                | Language | Value
I_HAVE_A_RED_APPLE | en-US    | I have a red apple.
I_HAVE_A_RED_APPLE | es-MX    | Yo tengo una manzana roja.

Select allOpen in new window

Then, have a process that takes the database values and dumps them to a language-specific flat file that can be included in your custom code. So for example:

if($end_user_language == "en-US")
{
  include("lang/en_US.inc");
}
elseif($end_user_language == "es-MX")
{
  include("lang/es_MX.inc");
}
...etc...

Select allOpen in new window

That presumes the content of these files is simply something like this:

en_US.inc

<?php
$__I_HAVE_A_RED_APPLE = "I have a red apple.";

Select allOpen in new window

es_MX.inc

<?php
$__I_HAVE_A_RED_APPLE = "Yo tengo una manzana roja.";

Select allOpen in new window

And you can then use $__I_HAVE_A_RED_APPLE in your template. By using a flat file that matches your values in the database, you'll put less strain on the database, and you'll have the flexibility to even take it a step further, like storing the files on a ramdisk or memory cache for faster I/O. Meanwhile you can use the database to manage the strings easily.

Don't try to combine logic with localization. Localization should simply be about proper display of the text. Things like acceptable range of values of inputs that might reside NEXT to a label should be handled completely separately.

Hi,

Wouldnt storing it in a database be an overburden?

You would need to create the file from the language and either you limit the results to create it faster and have to recreate/make a new page

or

you fetch it all at once and then include a massive library of variables to be replaced into text

Wouldnt the second option be almost the same as gettext

Storing in the database would provide you with easier management of the content. The database content would then be dumped (upon changes) to the flat files, which would work as an on-disk cache.

Yes, the option is similar to gettext, but doesn't require the gettext extension or the extra setup.

In your method, should the dumped file contain variables or constants as that would allow more flexibility

So constants in compiled languages are usually a good thing, but their performance in PHP is terrible. Here's how the performance pans out using different options:

Option #1: Constant Substitution

define("MYCONSTANT", "My content");
$content = "Surrounding content" . MYCONSTANT . "Other surrounding content";

Select allOpen in new window

Option #2: Class Constant Substitution

class Language
{
  const MYCLASSCONSTANT = "My content";
}
$content = "Surrounding content" . Language::MYCLASSCONSTANT . "Other surrounding content";

Select allOpen in new window

Option #3: Variable Substitution

$MYVAR = "My content";
$content = "Surrounding content" . $MYVAR . "Other surrounding content";

Select allOpen in new window

Option #4: Search and Replace

$MYVAR = "My content";
$content = str_replace("{MYVAR}",$MYVAR, "Surrounding content{MYVAR}Other surrounding content");

Select allOpen in new window

I downloaded a text version of the King James Version of the Bible (a little over 4 megs of text content), and then swapped out the word "the" for constants/vars using the options above. There were a total of 62,103 instances of the word "the" that were swapped out. The performance results:

Option #1: Constant Substitution - 64.4 seconds to execute
Option #2: Class Constant Substitution - 58.8 seconds to execute
Option #3: Variable Substitution - 0.10 seconds to execute
Option #4: Search and Replace - 0.025 seconds to execute

So option #4 performs best by far. I'd recommend sticking to a search-and-replace type of methodology. So in your dump file, you could build out an array, like:

$_TEMPLATE = array(
  "{HELLO_WORLD}" => "Hello world!",
  "{MY_CONTENT}" => "My content",
  "{YOUR_CONTENT}" => "Your content",
);

Select allOpen in new window

...and then replace it like this (assuming your $template is a string like "Blahblah{HELLO_WORLD}blahblah":

$final_content = str_replace(array_keys($_TEMPLATE), $_TEMPLATE, $template);

Select allOpen in new window

Wow

Thanks that gives me that answers i was looking for!