Branching of contact.tpl.php for oc.pl and oc.nl about opencaching-pl HOT 16 CLOSED

No, creating additional tpl for each site is not good idea. Also removing the 
tpl is not what we want to perform.

We can solve it this easy and universal way:

Convert current tpl into one universal cross-servers .tpl schema, contains no 
hardoded data, but place witch variables to display. 
All data, which are not the same [pl]/[nl]/[other possible site] like names, 
links, descriptions put in settings.inc.php as array, to be possible iterate 
and automatic display not depend on count of information.
in php engine just take data to display from config and language file.

I deliver example later.

in settings.inc.php:

$contactData = array(
    1 => array (
          'groupName' => 'Rada Rejsu',
          'groupDescription' => 'rrDescription' //identifier in lang file
          'emailAddress' => 
          'link' =>
          (....)
    ),
    2 => array(
          'groupName' => 'Rada Techniczna',
          'groupDescription' => 'rtDescription'
          (... here can be as many group like COG etc as neededm and each server 
          can have diffrent count of groups, as I know for example OCNL only 
           one gropup  ...) 

);

then in php engine make iterate

foreach ($contactData as $group){
    make html to display deatils here using also translate engine, 
    use of tr($group[$groupDescription])to translate thing like:
    'rada techniczna is group of programmers who make your life better..'
}

and finnaly push generated code to tpl.

Are you able to do it Boguś?

I'm willing to do this; but first, Harrie, please provide translated 
contact.tpl.php (or other translated data) in the attachment, and reassign the 
issue back to me when done.

Before implementing the change, I'd like to make sure that the idea fits final 
user requirements.

Boguś, you do not need Dutch data. Settings.inc.php are not commitable and 
diffrent each server. (even diffrent on local developers machines) Only one 
requirement is the variable name you create must be the same each server and 
developer machines. But can contain diffrent data. This way we keep data like 
server name or diffrent settings ocPL/ocNL for geoPaths and many other things 
diffrent each server.

So when you are ready, copy your array from settings.inc.php to 
settings-example.inc.php and commit only settings-example.inc.php file. Then 
inform RT and Harrie, and give us some time to update our settings. After 
Harrie and Aomeone from Polisch RT write you, that changes are applied to 
production server settings.inc.php, you can commit whole solution.

Ok, I know the technical details about settings.inc.php on devel, and 
production servers, and I understand your idea very well. But my question is - 
are those groups sufficient for Harrie's needs? Maybe he would like something 
completely different, that does not fit those groups idea? That's why I'd like 
to first see what is the final concept (the final page for oc.nl - maybe not 
with exact text), to make sure that we are not implementing something, which - 
from the starting point - is not enough, or even worse completely wrong. I hope 
I'm clear. If not, here is in Polish.


Chodzi mi o to, że nie wiem, czy Harriemu wystarczą inne grupy z innym 
tekstem. Zauważ, że w obecnym pliku jest kilka nagłówków h1, w nagłówku 
"OpenCaching PL Team" jest jakby kilka punktów, itd. Dlatego chciałbym, żeby 
Harrie najpierw zapodał to, co chce widzieć finalnie, później zobaczymy, 
czy Twój pomysł wystarczy do tego, żeby to zaimplementować, a jeżeli nie, 
to będziemy go poprawiać. 

Ok, let's wait for Harrie comment. 

But,

If we plan structure well, it will be suitable both OCNL, OCPL and for future 
another servers, and easy configurable without programmers attention needed.

at the moment we have 4 section. one section contain contact to RR/RT/COG has 
diffrent structure that rest 3 sections, and can be done via array I wrote 
before.

To make work easy you can move this section up, to the first place


rest 3 sections have similar structure each other.

I'm not sure if this sections need to be diffrent PL/NL.

So if PL/NL are not similar witch these 3 sections and we need to have diffrent 
data, You can put it to second array in settings + lang files.

 In my opinion Can be unified to  - 
header / description / link 
(section Zadawanie pytań o Geocaching can be split to 2 separate sections: 
forum and wiki) 

But maybe these sections are universal and we do not need to change it more 
than move translation to lang files and replace links with data current present 
in settings.inc.php.

I am thinking to make the Dutch contact like the German. Look 
athttp://translate.google.nl/translate?sl=de&tl=pl&js=n&prev=_t&hl=nl&ie=UTF-8&u
=http%3A%2F%2Fwww.opencaching.de%2Farticles.php%3Fpage%3Dcontact&act=url

So, in my opinion 2 arrays. first one contain contact details/descriptions as I 
wrote before, and to be diplayed at top of the page.

second array for all sections to display bellow, somethong like that: 
$contactSections = array(
 1 => array (
    'header' => 'forumHeaderPL' //(lang file identifier)
    'description' => 'forumDescriptionPL'
    'link' => ...
    ),
 2 => array ( 
   'header' => 'openGeoWikiPL',
 ...

each server can have diffrent count of sections and diffrent data.

Is that idea clear for you Harrie? 

We have a forum and a wiki so this could work. Please do not ask me to program 
it. But if you or others can make it happen, please be my guest. This option is 
better than it is at this moment :-)

Solution draft commited to contact_info branch.

This issue was closed by revision r5674.

I can't see contact_info branch in Google code at this time, perhaps it has 
been merged some time in the past (?)

The solution with variable definitions in settings.inc.php, in my opinion is 
cumbersome and restrictive.

Current translation infrastructure replaces identifiers with a single line of 
text from translation file. It also supports {placeholder} (this gets replaced 
with contents of "placeholder" variable. 

Writing larger text is difficult. 
Some pages which contain [mostly] static information, but with complex HTML 
formatting cannot be handled this way. 

Using the variables defined in settings.inc.php is somewhat of an intermediary 
measure. 

I propose the following solution, which has the benefits of the existing 
translation infrastructure and extend it in such a way that larger fragments of 
language dependent text with HTML formatting can be handled : add include file 
capability to tr() function. 

Currently languages are defined in /lib/languages with each language being a 
single file named as the language 2 letter code, without extention.

I propose : 
/lib/languages/pl.txt --> the file containing the strings and their translation
/lib/languages/pl/file1.txt --> subdirectory for PL language containing 
includeable file named file1

string may contain {variable} to reference a variable
string may contain {include:file1} to reference pl/file1.txt

I know about tpl/stdstyle/articles, but the above suggested solution has the 
benefit of universality, not just limited to articles. 

=================================
Steps to implement: 
- make necessary changes to the code, tr() function
- copy /lib/languages/*. to /lib/languages/*.txt
- commit changes
- remove from repository /lib/languages/*. (files with no extention)
- commit changes
- at this stage no change should happen for end user or node operator
- create /lib/languages/XX/ directories and commit
- make changes to template files to reference strings that use file include 
(per language) and create the respective files with proper content under 
/lib/languages/XX/
- remove complex variables with such texts from settings.inc.php

End result: all per language content under /lib/languages/ with much better 
manageability. 

I think that most static text is not language specific, but installation 
specific, thus we should think about the ability to differentiate inclusions by 
node_id.

then both inclusion and node_id