Ditto Dito

Something like this should work (untested)

<?php if('de' == pll_current_language()) { ?>
    <h1>Deutsch</h1>
<?php } elseif ('en' == pll_current_language()) { ?>
    <h1>English</h1>
<?php } else { ?>
    <h1>Martian</h1>
<?php } ?>

Or, if you are already in a php block, you could rewrite the above into:

if('de' == pll_current_language()) {
    echo "<h1>Deutsch</h1>";
} elseif ('en' == pll_current_language()) {
    echo "<h1>English</h1>";
} else {
    echo "<h1>Martian</h1>";
}

I have added, as you can see, three possibilities: German, English, something else. Your exact question would be translated as:

if('de' == pll_current_language()) {
    echo "<h1>Deutsch</h1>";
} else {
    echo "<h1>Anything else</h1>";
}

But you get the idea.

Sorry, I have been re-reading the code and I figure I got that wrong. I assumed that the hooks would possibly modify the $translation variable. But that’s clearly nonsense. Just drop that.

Just downloaded the beta2 and saw it’s in already. Great!

Just out of pure curiosity: I see you trigger ‘pll_translate_media’ after having saved the translations. Not that I know anything about it, but doesn’t that mean that any changes from hooks are not saved?

Ultimately, that could be good or bad. I am just wondering.

What Chrystl said: Disable synchronization of custom fields but translate the slider’s contents (images, pages, whatever).

You wrote: “But this leads to a duplication of media that seems very heavy.”

Well, it depends on where you look. It will create 3 additional rows per image in the database, not more. You don’t have to upload the photos a second time. You duplicate the information about the image to be able to translate it, but not the image itself.

The question is: Do you need translated image properties (title, caption, description, alt) or not. If you uncheck the option, all your images will always be presented in the default language.

If you need translated image properties, then check ‘Media Translation’, goto the Media Library and create the translation for the images, like you would for any other post or page of your site.

For things to work, you may then need to check synchronization of custom fields as well. Or not.

I know that this is all confusing. I have been there. The problem lies in how WordPress handles media information. It’s not really a Polylang thing, you have exactly the same problems in WPML.

If you need translation on media, you could create the translations manually, or program a little helper to at least create dummy translations that you correct over time, one after the other. This is what I did for my image gallery. As a result, I had one gallery in several languages. Adding a photo to the gallery is automatically propagated to all languages.

I could give you my code, but the way WordPress works, this won’t be a copy-paste solution. Sorry for the bad news, don’t shoot the messenger.

Forgot to mention: I am on your 1.7 beta. So whatever I find will flow back into the right place.

Thanks!

Thanks for getting back to me. Still, that feels wrong to me: When I create a new language for an image, everything is copied, except ALT.

So why ‘caption’ and ‘description’ _is_ copied, when they usually are expected to be translated as well.

Similar with custom fields to attachments. Looking at the documentation of WPML, you can set these to “copy” or “translate”. Copy means they are always loaded from the original language, Translate means, well translate.

I any case, I find it better, more natural, to fill in copied language items as much as possible to
a/ help the translator with content and context
b/ have at least something to show, even if not translated yet.

Not a big deal anyway. I have added stuff to my translate_media() :
if($meta = get_post_meta($post_id, ‘_wp_attachment_image_alt’, true)) add_post_meta($tr_id, ‘_wp_attachment_image_alt’, $meta);
if($meta = get_post_meta($post_id, ‘_vu_image_tags’, true)) add_post_meta($tr_id, ‘_vu_image_tags’, $meta);
if($meta = get_post_meta($post_id, ‘_vu_product_sku’, true)) add_post_meta($tr_id, ‘_vu_product_sku’, $meta);

For completeness:

I know I can get the tags using

wp_get_object_terms($product->post->id, 'product_tag')

but find it strange that the real methods won’t work. There must be something I don’t see.