Issue with Translated Alt Tag Breaking Page Layout

Thank you, @jjbte, for figuring it out. The only problem is that I still do not understand why it worked under 3.0 and got broken under 3.1. I understand that closing tag [:] may help to fix it, and this is partly why it was introduced, but why it worked under 3.0 then? No, ending tag [:] is not required, but can help when things are broken. Maybe order of some filters is changed. I am not sure, should we spend time to figure it out?

The issue appears to be connected to the Alt tag. Under 3.0 (and earlier), Alt tags were not translated properly. They would simply display in the source code like [:en]English Alt[:de]German Alt (all language versions plus translation tags).

I’m assuming your team did something to improve Alt tag translation between 3.0 and 3.1. In 3.1, even without adding the closing [:] tag, the Alt tag is translated properly. It just doesn’t have the closing quotes, which causes a break in the page’s layout. Adding the closing [:] for each language fixes the Alt tag closing quotes issue and proper layout is restored.

Is it possible the closing quotes were just inadvertently left out in a related function? I haven’t had a chance to look at any of the plugin’s code as of yet. I figured I could get an idea of the issue’s cause by just looking at web-page source HTML code, so that’s all I did thus far.

Hello JJbte,

My theme have shortcodes for page design – https://portugalmyxperiences.com/

The instruction I am using is:

[raw][latest_offers items=”6″ title=”EXPLORE AS NOSSA úLTIMAS OFERTAS” link=”VEJA TODAS AS úLTIMAS OFERTAS!” href=”?tfseekfid=main_search&s=~&myxperiences=all”]

[tags title=”EXPERIMENTE HOJE MESMO!” latest=”false” latest_title=”Oportunidades!”]
[tag id=”134″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/TOP.png”%5D [tag id=”154″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/red.png”%5D%5Btag id=”155″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/yellow.png”%5D%5Btag id=”156″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/blue.png”%5D%5Btag id=”157″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/green.png”%5D%5Btag id=”158″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/orange.png”%5D%5Btag id=”159″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/green.png”%5D%5Btag id=”160″ icon=”https://portugalmyxperiences.com/wp-content/uploads/2015/01/red.png”%5D [/tags]
<div class=”divider_space”>[special_offers items=”6″ title=”PRE?OS ESPECIAIS E úLTIMAS PROMO??ES” link=”VEJA TODAS AS úLTIMAS PROMO??ES!” href=”?s=~&tfseekfid=main_search&promos”][/raw]</div>

This is guiving error for default language,but for translation works ok???
Maybe because I am using the []???
Thanks
Pedro

I think you’re better off loading the web page in question in your browser and then looking at the page’s HTML source code. Do that for both versions 3.0 and 3.1 and try to see what changes between the two versions. You could also try running the pages’ URLs through the W3C Validator to see if it detects any blatant syntax errors, or use a debugging tool like Firebug.

Comparing source code is how I discovered the Alt tags were messed up in my 3.1 pages. Apparently, for 3.1, Alt tags require the closing [:] tag in order to have their content properly closed with quotes in the final web page. Your issue appears to be something different.

@jjbte: I keep thinking what might be a reason that it worked in 3.0, and I though maybe 3.0 did not translate those alts at all (and nobody really cared since ‘alt’ mostly unseen), while 3.1 did translate it, but since there was no closing [:] it got broken? Could you confirm if in 3.0 they were also translated correctly?

For 3.0 and earlier, Alt attribute content was not translated. It would just appear exactly as it had been entered–all language versions and language tags.

In 3.1, Alt content is translated, but the closing [:] tag must be added or the final Alt content does not have its quotes closed properly, which breaks the page’s layout from that point forward. Fortunately, when you edit a photo using WordPress’s Media Editor (the full-page version with the language-switching buttons), the tags are properly constructed for you, for example:

[:en]English Alt[:de]German Alt[:pt]Portuguese Alt[:]

I noticed just one [:] is needed at the very end of the entire string, as opposed to the <!– tags which need a closing tag for each language. Note that it does appear to work just fine if you add a [:] tag after each language, though.

For existing photos with multilingual Alt content, users will have to go back and re-edit the photos using the Media Editor so they will have the new language tag structure. From what I saw on my test site, the Alt content was the only thing affected (titles, captions, and descriptions seem unaffected after the upgrade to 3.1).

This mainly applies to photos in photo galleries. Individual photos in pages and posts can be edited independently for each language version of the page/post. Photos in photo galleries generally rely on the information entered using WordPress’s Media editing tools. Like page and post content, this information goes into the database with appropriate language tags (e.g., [:en]).

Yes, this would now explain what happened. So, in other words, it was not working under 3.0, but now, in 3.1, it does work, but an additional step is needed to resave alt texts, so that they would get [:] tag. If you have a lot of pictures, manual re-saving can be very painful.

That is why I added step to update postmeta in “Convert Database”, which auto-convert alts as well. Use the latest version from GitHub, which you can download with ‘Download ZIP’ button on GitHub page or press here for the sake of convinience.

I confess I was apprehensive about running the Convert Database option in version 3.1. Not so much with regard to standard WordPress items (e.g., pages, posts, media), but with other plugins I have running (All-In-One SEO Pack, Jetpack). I always back up my site and database before installing updates, but I still felt uneasy about the auto-conversion.

So far, any existing content I have edited–including media, pages, posts, and AIOSEOP tags–has converted properly after editing. So, chances are, the Convert Database routine would have worked just fine. I haven’t had a change to get the latest version from GitHub yet. Hopefully soon…

You’ve done a great job getting this plugin to fulfill everyone’s varying needs.

I wanted to follow up with some additional info I discovered today. I have a test site using the Twenty Fifteen theme and the only active plugin is qTranslate-X. Today, I updated that site from qTranslate-X 2.9.8.9 to 3.2.1. The site has various example pages and posts, including sample photo galleries. Immediately after installing the update (BEFORE database conversion), I checked the photo galleries and found they were NOT adversely affected by the update. Their Alt content was translated properly and also had properly closed quotes.

These galleries are just the standard WordPress thumbnail galleries; the site where I experienced the broken layout (due to unclosed quotes for Alt content) is using Jetpack tiled galleries. We already know Jetpack doesn’t always play nice with qTranslate-X.

There are other differences as well–the “broken” site has a different theme and other active plugins. I also initially upgraded that site from 3.0 to 3.1, as opposed to this test site that went directly from 2.9.8.9 to 3.2.1.

I also ran the “Convert database to the ‘square bracket only’ style” on the test (Twenty Fifteen) site and everything went smoothly.