WordPress.org

Forums

[resolved] Translation function calls must NOT contain PHP variables (9 posts)

  1. AJ Troxell
    Member
    Posted 2 years ago #

    I am newer to WP plugin development and extensive Theme development. I am using and altering a theme options sample from ThemeShaper. My problem is localization and the structure of the theme-options.php file.

    I know that this is improper: esc_attr_e( $options[$input['Input']] );

    But I know not how to restructure it so that it is proper, but figured it would be something like this: esc_attr_e( _n('%d', '%d', $options[$input["Input"]], 'white'), $options[$input["Input"]] ); yet all this does is fill my fields with a value of %d.

    Can anyone lend me a hand on how to make this proper?

  2. bcworkz
    Member
    Posted 2 years ago #

    I'm not sure I can help, but my curiosity would not let me pass this one by. Cannot contain variables??? Where is this coming from? Functions are not very useful if they cannot accept variables. All the l10n functions in the Codex show examples with variables. Can you explain further?

  3. AJ Troxell
    Member
    Posted 2 years ago #

  4. I know that this is improper: esc_attr_e( $options[$input['Input']] );

    Can anyone lend me a hand on how to make this proper?

    Sure.

    It is not possible to make that proper, because what you're doing makes no sense in the first place.

    Translation is meant to happen on fixed strings. So a string like "yes" becomes "sí", or "oui", or "ja". This is done by replacing the fixed text in your code with text from some translation file that literally has "yes" = "ja", for the German case.

    Presumably, $options[$input['Input']] is some string that is coming from user input in some way? In which case, it cannot be translated. Why? Because it isn't running things through Google Translate here. It's doing a lookup in the MO file and finding the appropriate pre-translated string.

    But, what is in $options[$input['Input']]? It's an array of something, and you're using $input['Input'] as an index to that array. If, somewhere, there are strings of text, then they need to be translated there, where they are defined, probably using the __() function. And here, where you have the esc_attr_e() function call, you need to be using echo esc_attr() instead. Translation belongs where the strings of text are.

  5. Also, yes, that theme-options.php file from ThemeShaper is doing it wrong there too. It's from 2010, and everybody makes mistakes. :)

  6. AJ Troxell
    Member
    Posted 2 years ago #

    Thanks for the clarification Otto. Learning as best I can.

  7. AJ Troxell
    Member
    Posted 2 years ago #

    Resolved

  8. LinkeLoutje
    Member
    Posted 1 year ago #

    Hmm you mention it is resolved, but I'm curious about how you should tackle the problem of translating theme options. What is the best way to go?

  9. bcworkz
    Member
    Posted 1 year ago #

    As Otto said, trying to translate user input is simply not possible due to how WP manages translations. You can certainly translate option labels, just not user input. If user input must absolutely be translatable, they would have to select from pre-established values, such as a dropdown select/option input field.

    If you have more questions, please start a new topic instead of dragging up old threads, thanks.

Topic Closed

This topic has been closed to new replies.

About this Topic