Closed GoogleCodeExporter closed 9 years ago
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.
Original comment by wloczynutka
on 22 Jan 2014 at 10:16
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ś?
Original comment by wloczynutka
on 22 Jan 2014 at 10:32
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.
Original comment by boguslaw...@gmail.com
on 22 Jan 2014 at 10:43
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.
Original comment by wloczynutka
on 22 Jan 2014 at 10:54
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ć.
Original comment by boguslaw...@gmail.com
on 22 Jan 2014 at 11:07
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.
Original comment by wloczynutka
on 22 Jan 2014 at 11:27
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
Original comment by henricus...@gmail.com
on 22 Jan 2014 at 11:29
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?
Original comment by wloczynutka
on 22 Jan 2014 at 11:45
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 :-)
Original comment by henricus...@gmail.com
on 22 Jan 2014 at 11:57
Original comment by boguslaw...@gmail.com
on 23 Jan 2014 at 1:06
Solution draft commited to contact_info branch.
Original comment by boguslaw...@gmail.com
on 23 Jan 2014 at 3:29
This issue was closed by revision r5674.
Original comment by boguslaw...@gmail.com
on 23 Jan 2014 at 8:14
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.
Original comment by andrixnet
on 12 Sep 2014 at 7:12
Original comment by andrixnet
on 12 Sep 2014 at 7:13
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.
Original comment by boguslaw...@gmail.com
on 16 Sep 2014 at 9:01
then both inclusion and node_id
Original comment by andrixnet
on 17 Sep 2014 at 6:28
Original issue reported on code.google.com by
boguslaw...@gmail.com
on 22 Jan 2014 at 10:03