[TYPO3-german] f:link.page auf versteckte Übersetzung

Thu Jul 24 15:07:01 CEST 2014

Hallo David.

Wenn du wirklich "sys_language"-Tabelle um ein Feld erweitert hast dann kommst du da aus dem stdWrap im Sprachmenü zunächst mal nicht ran.
Wenn das Menü auf "special = language" steht, sind trotzdem weiterhin alle Menü-Items jeweils Seiten, keine Sprachen.

Beispiel: Es gibt die Sprachen 0, 1 und 3 auf die Seite 1234 und haben somit drei TMENUITEM.
Die drei TMENUITEM sind aber alle die gleiche Seite mit der ID 1234.
Wenn du im stdWrap auf "data = field : uid" zugreifst, wirst du jeweils die "1234" finden.

Du hast es also auch im Sprachmenü mit Seiten zu tun, nicht mit Sprachen.

Der einzige verlässliche Sprachindikator (den du mittels TypoScript "gettext" abfragen kannst) steht übrigens in "field : _ADD_GETVARS".
* Beim ersten Menüeintrag ist der entweder leer oder mit "&L=0" vorbelegt (Standardsprache).
* Beim zweiten Menüeintrag ist er "&L=1" für die Sprache mit der ID 1
* Beim zweiten Menüeintrag ist der "&L=3" für die Sprache mit der ID 3

Du musst dir also auf jeden Fall eine kleine Hilfs-PHP-Funktion schreiben, die dir z.B. mittels "parse_str($this->cObj->data['_ADD_GETVARS'], $addGetVars);" den konkreten Wert der L-Variable ermittelt. Erst dann kannst du die sys_language-Tabelle auslesen und den zugehörigen Link zur externen Seite ermitteln.

Das alles ist relativ unschön. Das Problem ist aber eben, dass du innerhalb des Renderings der TMENUITEMs nicht mehr auf die Sprache des Menüeintrags zugreifen kannst.
Zauber dir einfach mit USERDEF1 und einer eigenen userFunc eine geeignete Stelle für einen Breakpoint und schau dir $this->cObj->data an sowie TSFE->register. Auf viel mehr kannst du mit getText nicht zugreifen, und alles was da nicht drin steht musst du dir selbst ausdenken.

Gruß,

Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Website: media.netlogix.de

------------------------------------

E-Mail-Archivierung – Rechtssicher, wirtschaftlich, clever
Jetzt anmelden zum kostenlosen Webinar am 29.07.:
http://it-training.netlogix.de/angebote/webinare/mailstore

-----Ursprüngliche Nachricht-----
Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von David Greiner
Gesendet: Mittwoch, 23. Juli 2014 17:31
An: typo3-german at lists.typo3.org
Betreff: Re: [TYPO3-german] f:link.page auf versteckte Übersetzung

Hi Stephan!

Vielen Dank für die umfangreiche Antwort.
Das von dir vorgeschlagene ist ja auch ziemlich Umfangreich. Ich überlege gerade ob es nicht evtl. möglich wäre, das ganze mit Hausmitteln, sprich dem normalen TypoScript Languagemenu, zu lösen.
Soweit ich weiß gibt es ja den USERDEF1 Zustand, der dafür zuständig ist, Links für nicht existente Seiten zu definieren.
Man müsste dann im stdWrap.typolink.parameter das extra hinzugefügte Feld abfragen. Aber genau daran scheitert es bei mir. Entweder weil ich mich einfach nicht klug genug anstelle, oder, was schlimmer wäre, diese Möglichkeit einfach nicht besteht.

Vielleicht kommen wir gemeinsam zu einem guten Lösungsansatz.

Gruß, David.

Am 23.07.2014 17:05 schrieb Stephan Schuler <Stephan.Schuler at netlogix.de>:
>
> Hallo David.
>
> Ich stoße auch regelmäßig an diese Stelle und ärgere mich ein wenig.
>
> Die einzige Stelle im TYPO3-Core die die von dir angesprochenen Checkboxen berücksichtigt ist das Menü, genauer gesagt das AbstractMenuContentObject. Es gibt keinen ViewHelper dafür, keine Overlayfunktion und keinen stdWrap.
>
> Um grundsätzlich den Wert der Checkbox auszulesen muss die Property "l18n_cfg" einer Seite in GeneralUtility::hideIfNotTranslated() geworfen werden, raus kommt dann TRUE oder FALSE und gibt an, wie sich verhalten werden soll wenn keine Übersetzung existiert.
>
> "Das Menü" bedeutet aber in diesem Fall: Sowohl das Seitenmenü, das ab einer anzugebenden Startseite eine anzugebende Zahl an Treelevels rendert als auch (Trommelwirbel) das Sprachmenü, also das Menü mit "special = language" und "special.value = {$uidsOfAllowedLanguages}". Und natürlich auch alle anderen specials, wie rootline oder update.
>
> Ich bin bei Menüs, auch bei Sprachmenüs, bisher immer der Einfachheit halber beim TypoScript-Menüobjekt geblieben. Gerade solche Feinheiten wie "Seite im Menü verbergen" oder "Nur Seiten anzeigen die in dieser Übersetzung vorhanden sind" sind leider bislang nicht anderweitig implementiert.
>
> Als Implementierungsidee könnte ich mir vorstellen, "irgend ein" Menü als Standard-HierarchicalMenu-Objekt innerhalb eines MenuViewHelpers (den es noch nicht gibt) zu erzeugen (unabhängig davon ob das jetzt ein Seitenmenü ist, ein Sprachmenü oder eines der anderen "special"-Varianten), das sich ergebende HTML dann durch einen XML-Parser (das DOMDocument bietet sich hier an) zu schieben und so den Coreoutput in ein eigenes "Menu" DomainObject zu verwandeln. Das lässt sich dann im ViewHelper in den den templateVariableContainer übergeben und kann man durch Partials und Nesting ein ganz hervorragendes Menü bauen, ohne dabei auf die unzähligen Mächtigkeiten des Coremenüs verzichten oder die nachbauen zu müssen.
>
> Das ist jetzt zwar keine wahnsinnig elegante Variante. Sie hat aber den Vorteil, dass die gefühlten 1000 Eigenheiten des Menüs alle erhalten bleiben. Checkbox "Seite im Menü verbergen" zum Beispiel oder die diversen "special"-Möglichkeiten (directory, list, update, rootline, browse, keywords, categories, language), alles das was das bisherige Menü schon kann will man eben einfach nicht nachbauen sondern möglichst die Features aus dem Core nutzen.
>
> Wer eine bessere Idee hat: Immer raus damit. Allerdings führt "einfach alle Seiten selbst abfragen" erfahrungsgemäß von einem fehlenden Feature ins nächste.
>
> Gruß,
>
>
> Stephan Schuler
> Web-Entwickler
>
> Telefon: +49 (911) 539909 - 0
> E-Mail: Stephan.Schuler at netlogix.de
> Website: media.netlogix.de
>
>
>
> ------------------------------------
>
> E-Mail-Archivierung – Rechtssicher, wirtschaftlich, clever Jetzt
> anmelden zum kostenlosen Webinar am 29.07.:
> http://it-training.netlogix.de/angebote/webinare/mailstore
>
>
>
> --
> netlogix GmbH & Co. KG
> IT-Services | IT-Training | Media
> Neuwieder Straße 10 | 90411 Nürnberg
> Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
> E-Mail: info at netlogix.de | Internet: http://www.netlogix.de
>
> netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
> Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
> Umsatzsteuer-Identifikationsnummer: DE 233472254
> Geschäftsführer: Stefan Buchta, Matthias Schmidt
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von David Greiner
> Gesendet: Mittwoch, 23. Juli 2014 09:50
> An: typo3-german at lists.typo3.org
> Betreff: [TYPO3-german] f:link.page auf versteckte Übersetzung
>
> Hallo Liste!
>
> In einem Projekt habe ich ein Language-Menu mittels Extbase/Fluid selbst zusammengeschraubt.
> Da es einige Sprachen gibt, die noch nicht im System integriert sind, es aber eine entsprechende Webseite unter einer anderen Domain gibt, habe ich sys_language um ein Feld "Link zu externer Seite" erweitert.
>
> In meinem Sprachmenü wird nun über die angelegten Webseiten-Sprachen iteriert und das Menü ausgeben. Entweder landet man auf der externen Seite oder - so vorhanden - auf einer entsprechenden übersetzten Seite des TYPO3-Systems.
>
> Nun passiert folgendes:
>
> In der Default-Sprache sollen einige Seiten nicht angezeigt werden (Hide default translation of page). Dies berücksichtigt mein Sprachmenü nicht, da es dem QueryString der aktuell aufgerufenen Seite lediglich den L-Parameter anhängt.
> Nun habe ich auf der deutschen Seite Links zu Übersetzungen in der Default-Sprache die eigentlich gar nicht angezeigt werden sollen.
>
> Hat jemand eine Idee, wie ich das clever berücksichtigen kann?
> Jeden Link durch einen extra Viewhelper zu jagen um die uid herauszufinden und zu überprüfen ob die Seite in der Default-Sprache angezeigt werden soll oder nicht, halte ich für ziemlich unperformant. Was anderes Fällt mir aber auch nicht ein.
>
>
> Gruß, David.
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german