[TYPO3-dev] Translation handling in the TYPO3-extension t3blog

David Bruchmann david at bruchmann-web.de
Wed Sep 29 13:13:17 CEST 2010


Hy,

working on making t3blog translatable I've some questions / ideas which 
you can find in the last chapter of this post.
The other chapters are for newbies and perhaps for clearance.

Thanks in advance for your ideas and comments.
David



Translation handling in the TYPO3-extension t3blog
---------------------------------------------------
---------------------------------------------------

Translation handling in t3blog is a bit tricky because the structure of 
blogs is unusual for TYPO3.
First the general handling of CEs on a page is explained for usual pages 
and for t3blog-enabled pages:

Structure 1) The normal structure for CEs (Content-Elements):
-------------------------------------------------------------
- page
-- CE_1
-- CE_2
-- ...
-- CE_n

The choice of the page shows the included (enabled) CEs.


Structure 2) On t3blog enabled pages the structur is like this:
---------------------------------------------------------------
- page
-- blogPost_1
--- CE_1
--- CE_2
--- ...
--- CE_m
-- blogPost_2
--- CE_m+1
--- CE_m+2
--- ...
--- CE_n

The choice on the page shows the included (enabled) blog-posts.
CEs are included by the plogposts but as long as a connection to any 
blog-post is missing, CEs shouldn't be displayed in the blog-content-area.
This behaviour depends on the installation-specific configuration and 
may depend on frames, cols or other areas on the page.


Translation handling in a simple way - and what's wrong with it
---------------------------------------------------------------

On a translated page in TYPO3 there are 3 different language-settings 
that should be shown dependent on configuration:
1) Language-Setting "ALL" should be displayed for all languages.
    This state is represented by the sys_language_uid-value -1.
2) Language-Setting "default" (or more) should be displayed in 2 cases:
    a) when the default-language is shown
       This state is represented by the sys_language_uid-value 0.
    b) when a fallback is configured. Dependent on the configuration a 
fallback-mode fetches another translation as fallback-language than 
"default".
       This state is represented by the sys_language_uid-value 0 or some 
other / more uid's.
3) Elements with the translation language should be shown in any case.
    This state is represented by the current sys_language_uid mostley 
defined as post-variable "L".

A simple SQL-query with the additional WHERE-clause
	" AND sys_language_uid in (-1, ".intval(t3lib_div::_GP('L')).")"
can handle the points 1) and 3) and with a bit more code the point 2a) 
could be programmed in the blog-classes, but
the point 2b) requires usage of the core-api to get the right 
translations for the current record.

Better translation handling
---------------------------

A better translation handling is quite simple.

1) At first each record with one of the sys_language_uid -1 or 0 is 
fetched from the database:

		$RES = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
			$fields,
			$table.$additionalTables,
			$where." AND sys_language_uid in (-1, 0)",
			$groupBy,
			$orderBy,
			$limit
		);

2) afterwards the required translation is fetched by a core-function:

		while (false !== ($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($RES))) {
				// Language overlay:
			if (is_array($row) && $GLOBALS['TSFE']->sys_language_contentOL) {
					$row = 
$GLOBALS['TSFE']->sys_page->getRecordOverlay($table,$row,$GLOBALS['TSFE']->sys_language_content,$GLOBALS['TSFE']->sys_language_contentOL);
			}
			... [functional part] ...
		}

This practice slows down the translated pages in comparison to the 
default language pages because more queries are done but speed isn't 
item of this text.
Furthermore always the right language for record is fetched, also 
several fallback-languages should be handled correct (-> point 2b) of 
"Translation handling in a simple way - and what's wrong with it").

Where is now the problem with t3blog?
-------------------------------------

In t3blog the practice of "Better translation handling" has to be done 
two times:
1) Once for the outer blog-posts
2) Twice for the inner CEs

Now some questions arise:
1) Concerning the inner CEs the question is now if the showed language 
in the backend is always the same which will be shown in the frontend.
2) Furthermore:
    a) should the language-choice of CEs be hidden to editors in the 
IRRE-view (or reduced to "ALL", "default" and language of the outer 
t3blog-post-element)?
    b) ... or what will be shown if an editor choses another language as 
the current blog-post-language or the default language for a CE (apart 
from "ALL")?
3) Can all requirements be implemented by one general configuration or 
are flags or parameters required for admins to determine some 
translation-behaviour in t3blog?
4) For untranslated CEs: should it be possible to translate them with 
some extension or external API (i.e.: Google Translate API)?
    If yes: can this done by the TS-setup of t3blog or has the 
possibility to be implemented in any kind in the PHP-code (parameters, 
hook(s), code, ...)?
    How should this implementation be realized concerning the outer and 
inner elements (t3blog_post, CEs)?




More information about the TYPO3-dev mailing list