CODEWITHSUNDEEP
typo3multilingualtyposcripttypo3-7.6.x
webman
webman

Reputation: 1203

TYPO3: language dependent variable that is hard-coded in a Fluid template

I have a multilingual site built with TYPO3 V7.6.18. It uses a slogan which should remain editable but different for three languages. This is a variable that is hard-coded in the Fluid templates.

For variables of this kind I use a file Configuration/TypoScript/constants.ts where I define the variable that can be edited (WEB -> Template -> Constant Editor) and used:

#---------------------------------------------------------------------
#   constants.ts
#---------------------------------------------------------------------

# customsubcategory=general=General Setup

myextension.configuration {
    general {
        # cat=myextension/general/05; type=string; label=Website Slogan.
        slogan= website slogan in main language
    }
}

[globalVar = GP:L=1]
    myextension.configuration.general.slogan = website slogan in second language
[end]

[globalVar = GP:L=2]
    myextension.configuration.general.slogan = website slogan in third language
[end]

I then bind the variable in Configuration/TypoScript/setup.ts for use:

#---------------------------------------------------------------------
#   setup.ts
#---------------------------------------------------------------------

page = PAGE
page {
    # Page Main template
    10 = FLUIDTEMPLATE
    10 {
        variables {
            # slogan
            slogan = TEXT
            slogan.value = {$myextension.configuration.general.slogan}
        }
    }
}

This code works, but only the slogan in the main language is editable ...

Any solution to make the slogans editable in the other two languages?

Upvotes: 4

Views: 980

Answers (2)

Mathias Brodala
Mathias Brodala

Reputation: 6480

I'd recommend to use language identifiers for the constants instead:

myextension.configuration {
    general {
        slogan {
          # cat=myextension/general/05; type=string; label=Website Slogan in default language.
          default = website slogan in main language
          # cat=myextension/general/06; type=string; label=Website Slogan in second language.
          second = website slogan in second language
          # cat=myextension/general/07; type=string; label=Website Slogan in third language.
          third = website slogan in third language
        }
    }
}

Then move the condition to the setup:

page = PAGE
page {
    # Page Main template
    10 = FLUIDTEMPLATE
    10 {
        variables {
            # slogan
            slogan = TEXT
            slogan.value = {$myextension.configuration.general.slogan.default}
        }
    }
}

[globalVar = GP:L=1]
    page.10.variables.slogan.value = {$myextension.configuration.general.slogan.second}
[end]

[globalVar = GP:L=2]
    page.10.variables.slogan.value = {$myextension.configuration.general.slogan.third}
[end]

Upvotes: 3

undko
undko

Reputation: 937

Three possibilities suggest themselves, two of which were mentioned by Mathias and Riccardo. I‘ll add a third one an list pros and cons of them.

So, firstly the third possibility which is to create a content element (preferably of type header) and create a TypoScript constant holding its uid.

# cat=myextension/general/05; type=int; label=Slogan CE UID
myextension.configuration.general.sloganUid =

Then fetch this content element‘s header in your fluid variable:

page.10.variables.slogan = CONTENT
page.10.variables.slogan {
    select.uidInList = {$myextension.configuration.general.sloganUid}
    table = tt_content
    renderObj = TEXT
    renderObj.field = header
}

Create a sysfolder, create a content element of type header and plumb its uid in your constant. Maybe you‘ll have to add some more stuff to .select to make it work - I‘m always unsure that.

Now pros and cons:

Three constants, as suggested by Mathias:

  • pro: Closed to what you did, easy, little code, no file access needed for changes
  • con: need to add another constant to constants and setup for each additional language

locallang.xlf:

  • pro: That‘s where you expect translations (in code), easy to add translations, can go to VCS
  • con: Needs file access to change

Content element:

  • pro: Admin can grant access to editors (if they want), easiest to add translations
  • con: adds DB queries (but normally cached), easy to screw up from BE

Upvotes: 4

Related Questions