Support » Plugin: qTranslate X » Odd Behavior with Photos and Photo Galleries

  • Resolved jjbte

    (@jjbte)


    I’ve noticed some issues when trying to insert photos and photo galleries into pages and posts. I am now using the latest version (2.9.5), but this issue has existed for me since my first download/install last week.

    For single photos: If I insert an existing photo with multilingual attributes (e.g., title, caption), it disappears after insertion if I update the page/post. WP must see the language tags as bad code or something. All that remains after update is some of the photo’s textual info. I’ve tried with both the square-bracket and angular-bracket versions of the language tags.

    I have found a way around this issue, though. Insert the photo, but do NOT hit the page/post’s Update button. First, make sure you’re in the Visual tab of the editor and the Language tab of choice. Click on the photo and select the edit (pencil) icon. Edit the photo’s attributes by removing any language tags and just leaving the attributes in the one chosen language. When finished, click the Update button of the photo editor, and then click the Update button for the page/post. Edit the photo accordingly for each language tab and you will have an appropriate language version of the photo for each version of your page/post. When done updating all pages, check the Text tab in each language because WP sometimes adds some extraneous p tags during the update process.

    For photo galleries: If I insert a photo gallery into a page/post, the same version of the gallery is inserted into all language versions. Because of the way galleries work (they just retrieve photo IDs), I don’t see how to include separate versions of the same gallery in different languages. What’s more, the language tags are not recognized properly. On the front end, all language versions of titles, captions, etc. appear side by side, and sometimes the language tags appear as well.

    I have not found a way around this one, except maybe to upload a separate version of each photo for every enabled language. The only reasonable option I can see at this point is to just have one language for all photo galleries.

    Interestingly, if you have the JetPack plugin and use its photo gallery widget to insert a gallery somewhere (e.g., a sidebar), the language tags do work properly. It seems to be the WP galleries for pages and posts that have a problem with the tags.

    I do have a few pages and posts where I need to include photo galleries, so I hope someone can figure this one out. 🙂

    https://wordpress.org/plugins/qtranslate-x/

Viewing 15 replies - 1 through 15 (of 29 total)
  • Plugin Author John Clause

    (@johnclause)

    Is this still an issue in the latest from github https://github.com/qTranslate-Team/qtranslate-x, otherwise please close the topic?

    I did not yet get to try adding a single photo that includes multi-language titles, etc. However, I did try a photo galley and there is no change; all languages and tags are still appearing with the gallery photos.

    I will try to post about this in the general WordPress forums to see if anyone has any input there. I might also try my theme creator’s support forum.

    Because I have suspected JetPack as the cause of this and other translation issues, I have been working with a WordPress installation with just qTranslate-X installed. I finally I had a chance to insert a photo gallery this evening and there are issues even with WordPress’s own gallery functionality. I can’t say whether there are issues with the image title attribute because WordPress galleries don’t appear to include that attribute, but the image caption is definitely not translated properly. The multilanguage captions all appear together with no spaces between. In the source code, they appear with the <!– tags between them. On the other hand, the image alt tag is translated properly.

    On the Edit Media page, The ID of the Caption input (textarea) is “attachment_caption.” I tried adding this to the ID field under Custom Fields on the qTranslate-X settings page, but it didn’t help.

    I am using the latest version from GitHub (2.9.8.1). Can you confirm that photo galleries are translated properly with a theme like Twenty Fifteen? I want to get to the bottom of this issue. If gallery translation works in other themes, then I’ll know the issue is related to my theme and I’ll ask its developer for help. Thanks so much.

    Plugin Author John Clause

    (@johnclause)

    No, galleries do not seem to show translated values automatically. The theme has to be adjusted at front-end, back-end is fine. Would you be able to look through code for what needs to be done in general? Are there filters we can simply enable? There are also bunch of gallery plugins with an alternative solutions for gallery display. Some of them may already do translation at front end. Have you done a research?

    Plugin Author Gunu

    (@grafcom)

    for example:

    this works with qTranslate X WP Photo Album Plus

    In researching WordPress gallery translation, I came across discussions of various gallery plugins having translation issues. I have not specifically looked for gallery plugins that translate properly. I’m trying to avoid adding another plugin. I only need a few pages to display some nicely arranged photos, so adding/maintaining another plugin just for that isn’t practical for my situation.

    I’m not an advanced programmer, and I am not intimately familiar with WordPress code. I have pinned down some of the files involved in both WordPress and JetPack gallery functions. Unfortunately, I can’t seem to find any possibilities for filters we could enable for translation.

    For the WordPress default gallery function, I thought simply applying the _e function to the caption would work, but I tried it on my test site and it just caused other issues:

    In wp-includes/media.php, changing line 1083 from

    wptexturize($attachment->post_excerpt)

    to

    wptexturize(_e($attachment->post_excerpt)) or _e(wptexturize($attachment->post_excerpt))

    did allow the captions to be translated, but it also caused them to appear in a single line at the top of the page rather than appearing over the photos upon hovering. I know changing core WP files isn’t a desirable solution anyway. I just wanted to try it.

    Since I will be using JetPack anyway, I intend to use its tiled galleries for my photo display pages. On my test site, I was able to add _e (or change esc_attr to esc_attr_e) to title, alt, caption, and description lines in “jetpack/modules/tiled-gallery/tiled-gallery/templates/partials/carousel-image-args.php” and “jetpack/modules/tiled-gallery/tiled-gallery/templates/partials/item.php” and achieve the desired results, even with “wptexturize( _e( $item->image->post_excerpt ) );”–the same code that does not work properly when tried in wp-includes/media.php above. That may have to be my “last resort” solution on my real site.

    I think I am going to try asking about this issue in the JetPack forum, but I’m not particularly confident I’ll get any help.

    Thank you for looking into this. You’ve really done a lot to fix various issues with this plugin. Maybe we’ll figure this one out at some point. I will keep looking over the code when I can, and I’ll let you know if I find any info that might actually be useful to you. Thanks again. 🙂

    Plugin Author John Clause

    (@johnclause)

    Hi @jjbte, please, try the latest from GitHub https://github.com/qTranslate-Team/qtranslate-x, which you can also download here.

    I hope that standard WP galleries will now be translated for you, but that required a pretty drastic change at very low level. Namely, I enabled filtering in WP_Query via hook do_action_ref_array( 'pre_get_posts', array( &$this ) );, which was otherwise disabled for galleries. You can search the code for the hook name, if you are interested. However, that will also enable filtering in many other places, which, in general, should be good, even better than before (some other places may not need filtering now), but it may have some hard to predict side effects.

    I would appreciate if you tested the whole thing (not only your problem) very carefully. Thanks a lot.

    You’re my hero!!! Caption and alt tags are being translated properly for standard WordPress galleries. If all image properties–Title, Caption, Alt, Description–have values, WP gallery uses Alt and Caption accordingly. It does not appear to use Title and Description at all.

    However, if Alt is empty for a given image, the wp_get_attachment_image function in wp-includes/media.php looks first to the Caption field and then to the Title field as a substitute for Alt. In either of these cases, the Alt value is NOT translated properly. So the Caption is translated properly for use as a caption, but not when it is used as a substitute for Alt. This is a very minor issue IMO. I usually fill in all fields for important photos, and not many users actually see the Alt text.

    For Jetpack galleries, all fields are now translated properly except for Alt. I did post about this and other minor translation issues in the Jetpack forum yesterday and they’ve asked me to post a pull request on their GitHub page, which I will try to do later today.

    I also looked at various other areas since you asked me to test. On my test site, I toggled the Hide Content setting to see the results. Either way, behavior is still as expected. When content is hidden, non-active language content, including menu items, do not appear. When not hidden, links to other-language content appear and work properly.

    I did notice one minor issue that may have existed before and I just didn’t notice. I recall you recently fixed an issue with double language parameters appearing in the URL when using the Search feature. Search is still working fine in all languages, but I noticed a double slash (//) appears before the query string in the URL when searching.

    Otherwise, I basically navigated around both my test site and the live site I’m building. I switched among my active languages and everything is working as expected, both in the web pages themselves and in their source code.

    The Admin area still seems fine as well. In fact, it looks like you even fixed the theme preview pane issue I recently read about in another thread.

    If there is something specific you’d like me to test, let me know and I’ll try. Thanks again for working so hard, and for being so attentive and responsive.

    Plugin Author John Clause

    (@johnclause)

    Thanks @jjbte: I added an item to “Known Issues” for the “if Alt is empty”. There is no really a good solution, since there is no WP hook in this place. I can only re-do again their algorithm, but with translation, under filter ‘wp_get_attachment_image_attributes’, which would hurt the performance a little bit. It can be an option to turn it on if needed. If you wish you can do pull request on it at our GitHub too.

    Thanks a lot, @jjbte, for you testing. This is very helpful. I could not reproduce ‘//’ problem though. It would be great if you could pin-point the place in the code at fault using your server, when it happens.

    The “Known Issue” approach is a really good idea. In my opinion, if someone is posting “important” photos, they should be carefully filling in all the fields anyway. It’s usually considered good practice to include Alt text for photos/images.

    Thus far, I have not been able to pinpoint any code changes that might help with WordPress standard gallery translations. The “_e” trick produced unexpected and unsightly results for the caption, and I have not yet gone through all the wp-includes/media.php code to see just where the Caption and Title values are initially retrieved. If I get to that point and get any ideas on what plugin changes might help, I’ll try them on my test site and try the pull request thing if they work.

    The “//” thing is happening on both my test site and the real one I’m building. I’m pretty sure it was NOT happening back when you fixed the double language parameter issue, but I have no idea when it may have started. If I initiate a search, the results page URL has a double slash (example.com//?s=search1). If I use the language switcher on the search results page, the language changes and the URL’s double slash goes away (example.com/de/?s=search1). If I initiate another search, the double slash comes back (example.com/de//?s=search2). I normally have the “Hide URL language information for default language” box checked under qTranslate-X’s Advanced Settings. I tried unchecking that box to see if that might be contributing to the issue, but it made no difference.

    I hope that information helps you. The double-slash thing is quite harmless since any browser I’ve ever worked with is forgiving of double slashes. Plus I doubt the average user will even notice. If I come up with any other ideas about what code could be causing the problem, I’ll let you know.

    Plugin Author John Clause

    (@johnclause)

    Actually, I still cannot reproduce ‘//’ problem. It may be coming from the theme? I guess, you are on your own to solve it, try to figure out after which function call it appears. Alternatively, you could give me a login to a test-copy of your site, where it happens, whichever is simpler for you.

    If you can’t reproduce the issue, it seems like it would have to be my theme or some other plugin. The two sites are running the same theme. When I first noticed the “//” the sites had one other plugin (AIOSEO) in common. I don’t recall if I had that plugin installed on the test site back when you first fixed the double language parameter issue (when I’m pretty sure the “//” issue did NOT exist).

    Anyway, please don’t fret over it. It’s probably not affecting anyone else, and it doesn’t affect the actual functionality of my site. The search feature is working as expected in all languages. The “//” is just a slightly annoying cosmetic issue that will likely go unnoticed by the majority of users.

    Thanks for looking into the issue and for all your time, effort, and help.

    Hello all,
    I guess I have a similar (or the same) issue.
    If I try to insert an image that contains alt and/or description in different languages, as soon as I update the page the image disappers leaving instead part of the code, and the pages in the other languages have also a mixed test in different languages and code.

    I think I understood that the problem is that the code is written, for example using en, fr and it, starting with the [en] code, than the image with that contains another [en] code, and than the rest… and it seems that this creates some confusion. Is this correct?

    [:en]<a href="..."><img class="..." src="..." alt="[:en]office_XC[:fr]bureau_XC[:it]ufficio_XC[:]"/></a>EnglishText[:fr]FrenchText[:it]ItalianText[:]

    By editing manually the page in the raw mode, moving the first[en] code after the image, i’m able to make it work… but it’s not very user friendly like this:

    <a href="..."><img class="..." src="..." alt="[:en]office_XC[:fr]bureau_XC[:it]ufficio_XC[:]"/></a>[:en]EnglishText[:fr]FrenchText[:it]ItalianText[:]

    Is there a way to solve this problem? I tried without success also the last pre-release version.

    Thank you,

    Raul

    Plugin Author Gunu

    (@grafcom)

    @raul85,

    if I’m right, you want the title and / or description of a picture in multiple languages.

    Go to – media – Library – Edit media

    use the language codes ([:en] [:fr]) in the fields – Caption – Alternative Text – Description

    Success

    Hello Gunu, thank you for the answer.

    I did exactly what you suggested to define title and description in the three languages. The problems begin when I insert the picture in a page: in that moment I have the issue with the code (that was the code of the page) that I described in the previous post.

    Could you help me?

    Thanks

Viewing 15 replies - 1 through 15 (of 29 total)
  • The topic ‘Odd Behavior with Photos and Photo Galleries’ is closed to new replies.