I've spent the last three days trying to find a robust path naming/linking scheme for my multilingual sites. The best results so far have been with Pathologic, but I feel that I still have a very long way to go...
I am working with language-symmetric paths like 'en/page' and 'de/page'.
For my links, I would like to use relative paths without language information, like href="otherpage".
From there, I would need that the language prefix get's attached magically:
- link to 'otherpage' from 'en/page' gives 'en/otherpage'.
- link to 'otherpage' from 'de/page' gives 'de/otherpage'.
Is such a thing possible? This would save me so much pain! (I really think that the authors should not have to translate every single path from 'en/somepath' to 'de/somepath', 'es/somepath', etc... This is just a huge source of errors.)
I am actually using the following modules:
- Path (Core)
- Locale (Core)
- Content translation (Core)
- Internationalization (Multilanguage)
'Public' file transfer, and 'Path prefix with language fallback' Language negotiation.
Comments
Comment #1
Garrett Albright CreditAttribution: Garrett Albright commentedSorry, but that falls outside of Pathologic's feature set at the moment. I might be willing to add it, but as I have zero experience working on multilingual Drupal sites, I wouldn't be the best person to do so at the moment.
Comment #2
jjalocha CreditAttribution: jjalocha commentedHmm... It's a sad truth, but it's good to finally know, that this is simply not a possibility today. I hope you (or someone else) can add this important feature some day, and, please, keep up the good work.
Thank you, Garrett!
Comment #3
mdupontComment #4
j0nathan CreditAttribution: j0nathan commentedLooks like the same issue.
I've just update from Drupal 6.16 to 6.17 and a couple of other modules. The images broke in other languages than the default one. English is not the default one. The paths of the images are /sites/default/files/xxxxx in the source and was modified to http://example.org/es/sites/default/files/xxxxx which is not good to get the images.
I had to disable the module pathologic and the images came back.
Comment #5
Garrett Albright CreditAttribution: Garrett Albright commentedJ0nathan, I think what you're mentioning is a different issue than what the OP is mentioning, but… yes, your problem is an acknowledged one; Pathologic is currently a huge fail on multi-lingual sites. Unfortunately, I'm not really familiar enough with multi-lingual sites to know how to fix this, and I'm hoping someone who is and has some programming chops may be able to help me. Might that be you?
Comment #6
meba CreditAttribution: meba commentedCan we make this a base for all language issues for Pathologic? I might be able to provide skills, I would like to see a list of all issues. Thx!
Comment #7
Vacilando CreditAttribution: Vacilando commentedSubscribing.
Comment #8
wmostrey CreditAttribution: wmostrey commentedRe #1: I don't think that i18n support falls out of the scope of any module.
I'm currently working on adding i18n support for this module since I it on a project I'm currently working on.
Comment #9
Garrett Albright CreditAttribution: Garrett Albright commentedwmostrey, #1 was posted more than two years ago, when I was young and dumb. You're right; i18n should have been included from the start, but I still feel that I don't know enough about the workings of i18n sites to do it properly, so I'm very grateful you've taken up the task yourself. If you'd like CVS access so you can easily submit your tweaks, just say the word.
Comment #10
meba CreditAttribution: meba commented@wmostrey Any idea about a timeframe? I am happy to help
Comment #11
Andy Inman CreditAttribution: Andy Inman commentedNot sure if I understand the original issue, but:
(1) Maybe you can do it with MultiLink
(2) I'd be willing to help, having done a lot of work with multi-language issues. MultiLink integrates with various other input filters that deal with links and paths - I can't see at the moment how to add any support for Pathlogic, but would be willing to do so if it might help.
Comment #12
meba CreditAttribution: meba commentedPatch attached.
Comment #13
NaX CreditAttribution: NaX commentedPatch seems to work for me. Thanks.
Comment #14
wmostrey CreditAttribution: wmostrey commentedWorks as advertised.
Comment #15
aschiwi CreditAttribution: aschiwi commentedPerfect, thank you!
Tested with site that has 2 languages, is using i18n. Can't think of that much more to test so setting this to RTBC.
Comment #16
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, I finally got around to taking a look at this…
I'm not totally satisfied by checking for "src" to determine if we should do rewriting or not. Instead, I'm seeing if we're using a valid menu writer file path, and if so, then doing the rewriting in a manner similar to meba's patch. This is "expensive" because it has to hit the database for every path Pathologic considers, but since Pathologic is an input filter and input filter results are cached, I don't mind too much if int means finally making Pathologic multi-language friendly. If you folks could revert meba's patch (use the -R flag with the patch command to revert a patch) and try my patch and let me know if it's any better or worse, I'd appreciate it.
Comment #17
Garrett Albright CreditAttribution: Garrett Albright commentedEDIT: (oops, posted in wrong thread somehow)
Comment #18
Andy Inman CreditAttribution: Andy Inman commentedBe careful, because the caching is not sensitive to language changes in D6 (it is in D7). I am not sure if this is relevant in the case of PathLogic, but in general you will get problems when the output of a filter is dependent on current language and caching is allowed. I addressed this issue in Language Sections and MultiLink via a patch (included with those modules).
Comment #19
wmostrey CreditAttribution: wmostrey commented@Garrett You say "If you folks could revert meba's patch (use the -R flag with the patch command to revert a patch) and try my patch" but I don't see a patch of yours in this issue?
The clean patch in #12 has been confirmed to work by four people so it's definitely worth considering.
Comment #20
Garrett Albright CreditAttribution: Garrett Albright commentedDammit, I forgot the patch so long ago? Here it is.
#12 may work, but I don't like the approach - if we're linking to non-Drupal things (like attached files, etc), the language bit will be attached and screw things up. Instead, we make sure we're linking to something within Drupal before we add the language bit.
Comment #21
lpalgarvio CreditAttribution: lpalgarvio commentedPathfilter managed to do it in someway.
take a look at their code - http://drupal.org/project/pathfilter
also please take a look at this issue: Duplicate language prefix
it states the problem of duplicate language prefixes when using i18n and pathlogic.
Comment #22
wmostrey CreditAttribution: wmostrey commentedI tested the patch in #20 which is already part of 6.x-3.x-dev, and it works exactly as expected. Since it's already part of the dev release I'm marking this as fixed.
Comment #23
Garrett Albright CreditAttribution: Garrett Albright commentedYeah, I got tired of waiting for someone besides me to test it, so I just pushed it. :P I'll go ahead and make a new release soon.
Comment #25
NaX CreditAttribution: NaX commentedI at first thought this patch was working, but later found that some images where still be prefixed with language prefixes.
After some debugging I found the problem was the
language_url_rewrite()
function. At first I assumed because it was doing aif (!isset($options['language'])) {
it could not be the problem but then I realized thatisset()
sees null variables as variables that are not set.By changing the
$language = NULL;
in the patch to$language = '';
the problem went away. I also though of changing the current language object to have no prefix or domain would also work, but I don't know what is that most correct method.Comment #26
Garrett Albright CreditAttribution: Garrett Albright commentedNaX, do you think you could try today's release (version 3.4)? It contains a patch from another multilingual-related issue which may fix your problem as well.
Comment #27
wmostrey CreditAttribution: wmostrey commentedUpdating the status: needs review from the 3.4 version.
(I'm not experiencing any issues with the previous version btw.)
Comment #28
NaX CreditAttribution: NaX commentedThanks Garrett Albright.
I have tested the latest workaround and it seems to be working as desired.
I also looked into my suggestions and this what I came up with.
You be the judge of what would work best long term.
NOTES:
I decided not to modify the domain variable as I cant see any reason to, but I don't have a domain based language setup available to test.
The drupal_clone() is required because we don't want to permanently modify the $language var. This is something I learned about recently on this issue http://drupal.org/node/832954#comment-3521672.
Comment #29
Garrett Albright CreditAttribution: Garrett Albright commentedNaX: I like what I see in your code, because it makes it so we don't have to temporarily reset site-wide variables like we're doing now (and as rightly pointed out in #961618: Language prefix should not be added to the path to files, is pretty crappy), but I'm kind of confused by the rest of your message. Are you saying that you've tested that code and it works?
Comment #30
NaX CreditAttribution: NaX commented@Garrett Albright
Can you point out what you are confused about? I have tested both solutions and they both seem to work. I am currently running my solution on a live 6 language website using language prefixes. My 2 notes are related to the domain part of the language object and the need to clone objects that we need to modify. Please note I did get a email this morning from my 6 language website client about another language problem. I have not looked into it yet but I don't think it is related to pathologic. I will let you know if it is.
Comment #31
apemantus CreditAttribution: apemantus commentedThis maybe a different issue, but I'm using the latest version of pathologic (3.4, not dev) and also Domain Access. If I write a link as
<a href="node/1">Link</a>
it works fine - i.e. on .com with default language as en, it rewrites it to foo and on .ch with default language as German, it rewrites it to en/foo. However, if the link is to<a href="foo">Link</a>
(as unfortunately every link on every page currently is) then it doesn't rewrite it on the .ch site, which I hoped it would.Comment #32
apemantus CreditAttribution: apemantus commentedOK; sorry if I'm busting in on the wrong issue or misunderstanding either a) pathologic or b) the menu system but:
menu_get_item only works on internal paths, not aliases, so aliased links weren't getting the language variable set. To get it to work then for aliases, I had to add in:
I don't know PHP's internals well enough to know if
if (menu_get_item($parts['path'])||drupal_lookup_path('source',$parts['path']))
would result in both drupal_lookup_path being run even if menu_get_item evaluated to true, hence the elseif.
The main issue seems to be that it's pretty intensive to run menu_get_items and drupal_lookup_path on every link and image and pdf on a page (especially as in my, edge, case I'm turning off caching for the input format). Is there a combined Drupal function that would work for both internal paths and aliases?
Alternatively, and I know this is never anybody's favoured solution, a simple regex would do fine in my case to test for the presence of a file extension.
Comment #33
hctomUnfortunately the current approach also does not respect the language of a menu item if this is set via the 18n menu module. So if you access an uncached node with a wrong language domain (e.g. node is in German, but it is accessed via the English language domain), the paths are evaluated using the global $language variable and not the language used for the menu item... which results in a wrong path. After that, the cached filter of the node will then output the wrong result for all languages you access the language dependent node in.
Comment #34
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, I've finally got around to working on this again. (I wanted to get the D7 branch at least somewhat functional again before I returned to working on the D6 one.) I've committed a fix which implements the improvements suggested in #28. If you guys could fetch the next dev release and give it a try, I'd appreciate it.
This is one difficult problem, compounded by the fact that I don't really maintain any multi-lingual sites myself, and I appreciate the help from everyone.
Comment #35
NaX CreditAttribution: NaX commented@Garrett Albright
I have been running my patch on a live and active site since posting #28 without any issues. I have had a look at your dev version and have tested it on this same site and it all seems to work correctly. So I am happy from my side.
Comment #36
ddanier CreditAttribution: ddanier commentedI updated the code from NaX to work with Drupal 7 (drupal_clone is gone here) and made a patch out of it. Hope this helps others to get the issue fixed fast.
Comment #37
SDC CreditAttribution: SDC commentedThank you so much ddanier! This patch is working great for me -- I thought I was going to lose my mind!
I'm developing a site locally and periodically uploading it to a temporary url to show my clients, and the temporary URL is an IP address/my hosting username (000.000.000.00/~username/), which is completely different from my local path (and the eventual URL). My image links were working fine locally, but as soon as I'd upload to the remote, almost all of my links were broken. Before your patch, I tried dozens of different combinations between the image paths I set in my nodes (/sites/default... vs. sites/default... etc) and different settings for Pathologic's "also considered local" setting. So I was testing different settings on my local English, local Spanish, remote English and remote Spanish, and it seemed that if I could get one or two to work, then the others would break. That pesky "/es/" language prefix kept popping up where I didn't want it. But your patch worked like a champ! Thank you, thank you! Hopefully this patch will make it into the next release...
I'm using:
Drupal Core 7.8
Pathologic 7.x-1.3 (with "/" added to "Also considered local" setting)
Internationalization 7.x-1.0
Maybe this will help somebody else with an image path problem: I created a spreadsheet to keep track of every node image path and Pathologic setting combination I tried with a column for Local English, Local Spanish, Remote English, and Remote Spanish nodes. Then for each test, I marked each column as OK or broken (using different colored cells for OK and Broken) and indicated how the image path was output by the browser (using Firebug to examine the images). This saved me a lot of time, because I knew exactly what worked or didn't and I didn't repeat the same settings twice.
Comment #38
Garrett Albright CreditAttribution: Garrett Albright commentedddainer, would it be too much to ask you to include some tests with the patch? Failing that, at least a concrete, step-by-step way to cause an error which this patch fixes? Pretend I'm a total n00b to multi-lingual sites (it's not far from the truth).
SDC, if you have an older version of that spreadsheet lying around where some of the paths were still red, I'd love to see it.
Comment #39
idflood CreditAttribution: idflood commentedPatch in #36 fix an issue I had with "insert" module. Here is a simple reroll, with manually corrected filepath directly in the patch.
Maybe it would be possible to merge it with another solution I had ( http://drupal.org/node/1156720#comment-4813106 )
Comment #40
Garrett Albright CreditAttribution: Garrett Albright commentedidflood, thanks, but do you think you could help me out with #38?
Comment #41
ingomueller.net CreditAttribution: ingomueller.net commentedHey everyone!
I do not think, that the proposed patch entirely solves the issue. The problem is, that the language of the URL is determined once and for all on creation of the page. However, what I'd suggest should happen is that the language is determined when the pages is loaded.
This means that, whatever language was active when the site was created, if the user loads the node through an URL with prefix "en", the URLs in the node should be rewritten to have the prefix "en". If the user loads with "de", it should be rewritten to "de". If the user loads with empty prefix, it should be rewritten to have an empty prefix. As I see it, this is how other links in Drupal behave (menus etc).
I guess that it'd be difficult to implement this, as not all results of Pathologic could be cached. There would have to be another pass when the node is rendered.
Cheers,
Ingo
Comment #42
ddanier CreditAttribution: ddanier commentedSorry, but I only updates the patch NaX provided to work with current D7. Not sure if the way NaX fixed this issue is the right way, but it worked for me. I'll try to reconstruct what exactly failed here.
Comment #43
fearlsgroove CreditAttribution: fearlsgroove commentedThis left a very sticky issue where pathologic would cache untranslated, unaliased node paths. The issue is that pathologic can run VERY early in the bootstrap process since a node is loaded as part of menu_get_item. This happens even before hook_init. So if one was to visit a spanish node at node/123, when pathologic processed it would have no idea what language it should be dealing with, so no matching alias, so would just cache the unaliased, unprefixed node/123 as the href.
This wouldn't be a big deal except that when using prefixes for language, those links would be redirected to the node's primary language version instead of directly to the version linked in the content. This happens even if using something like global reredirect since this whole transaction happens before hook_init.
When the object in question is a node, this patch adds to the other patches by checking the language of the node linked to and substitutes the language for URL alias with that of the node. It does so with a (soft) dependency on i18n, which seems reasonable, but we could also do a direct query for the node's language as well if there's any concern about that.
It also uses _menu_find_router_path to check if the path being worked on is a menu item instead of menu_get_item, which will load referenced entities in addition to checking if the path exists. In a page with a lot of internal links this can lead to quite a lot of unneeded overhead.
Sorry no tests yet but I'll try to get to that soon.
Comment #44
Garrett Albright CreditAttribution: Garrett Albright commentedAre you sure Pathologic is involved in that? Pathologic should only be running when text is filtered, which shouldn't happen unless it's about to be viewed in a web page. If a node is merely loaded, Pathologic doesn't do anything. I can't imagine menu_get_item is really rendering nodes as opposed to just loading them…
Have you verified this by way of debug_backtrace() or some other way?
Comment #45
fearlsgroove CreditAttribution: fearlsgroove commentedBelieve it or not, it does. node_load calls the entity controller load which calls the field attach functions, which will load and sanitize the text. It's doing so from cache usually so it's typically not expensive. But all this happens via menu_get_item which is called as part of the full drupal boostrap, before hook_init.
I've verified this by stepping through in eclipse to try to solve my phantom, unaliased, unprefixed links, which turned out to be caused by a googlebot visiting system URLs in certain instances rather than aliased and prefixed paths, which would trigger this issue.
Comment #46
rv0 CreditAttribution: rv0 commentedtested #36, worked and fixed my issue with image paths
tested #43 worked and fixed my issue with image paths
thanks for the patches!
It took some searching to find the problem was caused by Pathologic
Are tests needed for rtbc?
Comment #47
Garrett Albright CreditAttribution: Garrett Albright commentedYes, I need a test before I will commit it. However, I can probably write it myself if I could just get instructions for setting-up a multi-lingual site in such a configuration as to reproduce the undesired behavior, written in such a way that someone who's effectively a n00b at multi-lingual sites such as myself can easily follow along. Whether written by myself or someone else, though, I definitely want a test for this to go into the repo.
Comment #48
drupalerocant CreditAttribution: drupalerocant commentedPatch on #36 tested on Drupal 7.10 with pathologic 7.x-1.4 and i18n 7.x-1.2. At the moment solved the problem with the local images.
Thanks!
Comment #49
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, let's meet halfway here. I've tweaked a local version of my personal site so that it now can do content in English and Japanese. (And man, what a PITA that was… but even outside of this, I need to brush up on my multi-lingual skills anyway, so…) I have it configged so it does the path thing, so the English page is at
path
and the Japanese one is atja/path
.I can't seem to get it to behave unexpectedly, though. If I edit the Japanese page and put in a link to
path
, then clear caches and visit the English version of the page, then the Japanese one, the path on the Japanese page is still properly transforming tohttp://abweb.test/ja/path
. So I'm not triggering the bug.What more do I need to do?
Comment #50
NaX CreditAttribution: NaX commented@Garrett Albright
Also try something with image paths like with IMCE, and try editing a JA node in English IE: node/#/edit instead of js/node/#/edit.
I cant remember how I triggered this, it was a long while ago. If you don't figure it out I will have a look at it again in the new year when I get time.
Comment #51
fearlsgroove CreditAttribution: fearlsgroove commentedHi Garrett .. thanks for looking at it. Have you applied any of these patches, or are you just using the current -dev?
One issue this fixes is doubly or otherwise incorrectly linked paths to files or other non-drupal object. So add a link to a file, run it through pathologic and that field should incorrectly have a language prefix.
The other issue that I tried to fix in the #43 patch can be reproduced by:
The patch checks the language of the actual node a link is pointing to and inserts the correct prefix for that node regardless of the currently active prefix.
Clear as mud? :)
Comment #52
Garrett Albright CreditAttribution: Garrett Albright commentedI haven't applied any of the patches because, one, I still want to see the problem happen for myself first, and two, I'm going to rewrite the module so that it does less work in the regular expression and more in code. This will theoretically make Pathologic slower, but since its output is cached in all but very unideal situations anyway, I'm not going to sweat it anymore. It will also mean working with edge cases like this and all the others should be simpler. I've opened up a 7.x-2.x branch if you want to see how that's going, though I don't recommend installing it on a live site just yet (one reason being that I haven't figured out how the upgrade path will work yet).
At any rate, thanks for your instructions. I'll try to work with them tonight.
Comment #53
colanAdded tag.
Marked #1156720: Multilingual links in D7 and #1335412: Domain / i18n unaware: missing alias as duplicates of this issue.
I'm using field translation with the Entity translation module instead of node translation. (Aside: I strongly recommend that everyone switch to this method instead of using node translation in D7. It creates fewer problems with other modules, and is the where the community is headed.)
As expected with the 7.x-1.x branch, the translated URL aliases don't maintain their distinct language links when language switching. However, with the new 7.x-2.x branch, these links work perfectly. (Each node can have translatable fields. So in a translatable body field with English and French translations, switching between languages for that same node produces the embedded links with their proper language-specific URL aliases and domains, but only in the 7.x-2.x branch.)
Thanks for re-jigging this!
Comment #54
colanFixing settings.
Comment #55
Garrett Albright CreditAttribution: Garrett Albright commentedColan:
…Wow. I totally wasn't expecting anyone to actually use any code in that branch yet. Thank you.
Yeah, so it turns out that the language of a bit of text can actually be passed to a text filtering function, and my function can then turn around and pass that to the url() function. Why did I not know this before? I think it's because I built the first versions of the D7 version of Pathologic before this feature was available in the API, and never bothered to look at the relevant code since then. Yay, much less guesswork!
At any rate, I would appreciate it if everyone who wants to use Pathologic in a multi-lingual environment give the new 7.x-2.0-beta1 release a try. (And maybe try it if you don't have a multilingual site, too.) Configuration-wise, there's a minor difference; the "Also considered local" field is now labeled "All base paths for this site" (and may still change yet… I still have a hard time trying to figure out what to title this thing) and if you have any domain names in there, they should now be absolute, including http:// at the beginning.
Thanks in advance to all who can give this a try and let me know how it works for you. I know that I've said that I thought I had this problem figured out in the past, but this time I really think I'm on the right track… thank you all for your patience. And thanks again to you, Colan.
Comment #56
idflood CreditAttribution: idflood commentedI've updated pathologic from 7.x-1.3 to 7.x-2.x-dev and it fixed an issue on one website (the double language code). Thanks.
Comment #57
colanLooks like this is fixed then.
Comment #58
Garrett Albright CreditAttribution: Garrett Albright commentedI'd like to keep this open until I've made a full release and updated the documentation. That probably won't happen this weekend… But thanks for checking it out, and I'd still like to hear from any others out there who have given the 7.x-2.0 branch code a try.
Comment #59
palamida CreditAttribution: palamida commentedProblem with language prefix in files path still present in Drupal 7.10 + Pathologic 7.x-2.0-dev (Jan. 15)
But found this:
If I edit the node when site set in default language, and replace the broken link in the body with the correct link (even if nothing seems wrong with the link displayed in the IMCE popup window - i just confirm the link to the image)
save the node
voila... the images are visible
now if I change the site language to some other language, the images are still present
the only problem is that I must do this operation for all the nodes
Comment #60
palamida CreditAttribution: palamida commentedupdate to comment #59
paths to pictures and files in the body are OK only when I edit and save the node while the site is set to the default language - but only when the default language USE NO "PATH PREFIX LANGUAGE CODE".
:-(
Comment #61
jmones CreditAttribution: jmones commentedI experience the same problems as reported by @palamina in #60.
I've tried with -dev, -2.0-beta1 and git repository version.
Is there any other requirement regarding third party modules or any special configuration settings?
Comment #62
jmones CreditAttribution: jmones commentedI'm not sure, but I think that the problem might be derived from url() not able to build url without language for image files, even when we set options['language'] to ''.
I don't know drupal api well but image modules (and pathologic itself) seem to be using file_create_url() instead. So I made the following patch (to current dev) that, instead of setting $settings['langcode'] = 'und'; when we detect a file, it just returns the url.
Works for me but please take this just as a suggestion.
Comment #63
palamida CreditAttribution: palamida commentedOne question comes to my mind...
Why is pathologic dealing with language prefix code ?
Its primary (correct me if I'm wrong) intent is to correct everything that come before the drupal generated link...
what I did is to simply remove the language value in the url array (line 196 in the DEV version 15.1.2012.)
'language' => ''
and I got a working (at first sight) page
patch from comment #62 is partially ok - it fails with links inserted via linkit module
PS I'm not a developer, all I'm trying to do is speak my thoughts out so maybe someone smarter will come out with a solution
Comment #64
NaX CreditAttribution: NaX commented@palamida
I think that was looked into long ago, but I cant remember. I think stripping the language creates other problems. I commented about it in #25, but like I said I cant remember. Also most of this thread has been about D6. Maybe things are different in D7. I am not using D7 in product much yet and I have not done a multi language D7 site yet so I cant really comment. I suggest you test it your links in in more than one language and try editing a node in a different language than your current. EG: link to nodes of different languages.
When it comes to Linkit. I don't use it so I cant test, but maybe post the raw link code that gets inserted, maybe somebody will be able to help.
Comment #65
Garrett Albright CreditAttribution: Garrett Albright commentedI should probably mention that, in case you're not aware, just swapping in a new version of Pathologic will likely not cause links in your content to magically work. Since Pathologic does its thing right before content is cached, you'll need to clear your site cache so that Drupal will have to run your cotent through filters again and then Pathologic will have the chance to modify the content differently than it has in the past, if that makes sense. Since that cache is also changed when a node is changed and saved, that may explain the behavior you're seeing, palamida.
As for your suggestion in #63, this was more like how Pathologic worked before this 7.x-2.0 branch. The problem (among many) with this is that Drupal's URL building functions would use the "current" language to build the links. So if you had a node written in language A, but someone viewed it while language B was active in Drupal, all the links would try to link to the node using the language B prefix, and then cache that so it was broken for everyone. Since Drupal 7 now gives text filters a way to know what language a bit of text was written in when it goes to filter it, we use that to avoid the problem. Clearly there are still kinks to work out, but I think this is going to fix the big problem.
jmones, there would be problems if, for example, there were query parameters on that file path - like
<img src="image.jpeg?foo=bar" />
. This is rare, but sometimes useful and I don't want to break it. And as I said above, I bet palamida's problems could be solved with a simple cache clear - but, of course, I've been wrong before.And because it needs to be said now and then… Thank you all for helping test and improve Pathologic. You are all wonderful and attractive people.
Comment #66
dwalker51 CreditAttribution: dwalker51 commented#62 patch worked for me using pathologic-7.x-2.0-beta1
Comment #67
apemantus CreditAttribution: apemantus commented#62 patch works for me. Thanks!
Comment #68
palamida CreditAttribution: palamida commentedcleared the cache...
tried both 2.0-beta1 and 2.0-dev...
created a new node with different links in body
the problem is still present - language code prefix added to all links in body
in beta1 version the node language prefix code is being added to links
in dev version the active system language prefix code is being added to links
i'll try with a fresh new installation of drupal 7 and pathologic
Comment #69
dimitriseng CreditAttribution: dimitriseng commentedD7.10, pathologic-7.x-2.0-beta1. #62 has fixed the issue with files, thanks. Can somebody please confirm that this is the final solution?
Still having issues with linkit 7.x-2.1 + pathologic, but I think this is being investigated as part of #1221606: Linkit is on the input side and should not control how results are rendered.
Comment #70
idflood CreditAttribution: idflood commentedI stumbled upon this bug again with the 7.x-2.x. Here is a patch that adds a test to highlight issues with language_prefix.
On a side note the pathologic tests were failing even on a clean install so I created an issue for that #1426928: Make all tests pass, couple of changes
Comment #71
idflood CreditAttribution: idflood commentedHere is two more patches.
- The first one add a little fix for the double prefix. But since the tests are already broken it doesn't works well on it's own. It is working only if this is combined with the patch proposed in #2 of #1426928: Make all tests pass, couple of changes
- The second patch is simply a combination of the first patch with the patch in #70 that adds the test.
edit: #3 of #1426928: Make all tests pass, couple of changes has a patch combining the seconds patch with the patch #2 of #1426928.
Comment #72
dimitriseng CreditAttribution: dimitriseng commented@idflood - what about the patch at #63, are your patches compatible with that? Please see also my comments at 69. It looked to me that 7.x-2.0-beta1 with #63 had fixed the issue, although I have not tested it extensively and others seem to still have a problem. Thanks.
Comment #73
idflood CreditAttribution: idflood commentedI've done some different combination testing and found one another solution. Here is a summary of what happened:
without patch (only applied the one with the test in #70):
57 passes, 6 fails, 0 exceptions
result: "http://localhost/d7/fr//qux/abc/fr/a6RStY9w/oranges"
expect: "http://localhost/d7/fr/a6RStY9w/oranges"
with change proposed in #63:
57 passes, 6 fails, 2 exceptions
the two new exceptions are 'Trying to get property of non-object' in locale_language_url_rewrite_url():423
result: "http://localhost/d7//qux/abc/fr/msCu3c2y/oranges"
expect: "http://localhost/d7/fr/msCu3c2y/oranges"
with change proposed in #63 and patch #2 of #1426928: Make all tests pass, couple of changes:
63 passes, 0 fails, 2 exceptions
two same exceptions as before
the two new exceptions are 'Trying to get property of non-object'
result: "http://localhost/d7/fr/kdPIr8wp/oranges"
expect: "http://localhost/d7/fr/kdPIr8wp/oranges"
since there are just these two exception let's pass an object instead of '':
63 passes, 0 fails, 0 exceptions
result: "http://localhost/d7/fr/iH2qaQpH/oranges"
expect: "http://localhost/d7/fr/iH2qaQpH/oranges"
Here is a patch that include the test from #70 and the fix proposed above. It still require the patch #2 from #1426928: Make all tests pass, couple of changes to work completly.
Comment #74
palamida CreditAttribution: palamida commentedI did a clean installation BEFORE PATCHES FROM #70, #71 and finaly #73
Drupal 7.12
Pathologic 2.0-beta1 and 2.x-dev
the problem was still present
I applied the patch #4 (ONLY THAT ONE. am I wrong ?) from #1426928: Make all tests pass, couple of changes
and pictures are now ok
I must do some more testing with the linkit module
Comment #75
Garrett Albright CreditAttribution: Garrett Albright commentedThanks for all the work, idflood and everyone. I'm sorry I haven't been able to take a look at it, but my work flow has been kind of heavy recently. I'll try to get this looked at this weekend.
Comment #76
palamida CreditAttribution: palamida commentedafter applying the patch #4 from #1426928: Make all tests pass, couple of changes to 7.x-2.0-beta1-dev everything seems ok
Most of the tests I did on a clean installation... pictures and links are ok
I tried with additional modules:
Linkit 7.x-2.1
Internationalization 7.x-1.4
IMCE 7.x-1.5
Wysiwyg 7.x-2.1
Global Redirect 7.x-1.4
Redirect 7.x-1.0-beta4
Pathauto 7.x-1.0-rc2
...
and so far so good
Comment #77
colanIf there are multiple problems here, perhaps we should close this one, and open more specific issues?
Comment #78
dimitriseng CreditAttribution: dimitriseng commentedI had also tried patch #4 from #1426928: Make all tests pass, couple of changes and tested against beta1 and dev from 15/02 and all seemed to be working ok. However, beta2 does not include those changes and the patch does not apply cleanly. Is it possible to review the proposed changes in that patch and try to apply those to beta2+dev please, or update the patch to work with beta2? Otherwise beta2 will not work properly with multilingual sites, thank you.
Comment #79
idflood CreditAttribution: idflood commentedThe latest version of pathologic fixed most issues but not the multilanguage problem. The only thing needed was to change the language attribute of the url call. The following patch include the fix and the added test from #70.
Comment #80
dimitriseng CreditAttribution: dimitriseng commented@idflood - Thanks for providing the updated patch for 7.x-2.0-beta2. I have tested the updated patch at #79 with beta2 and as far as I can see everything seems to be working ok now as expected, files are also working.
@Garrett - Thanks for your good work on this. Can you please review #79 and commit if you are happy with this?
Also, I think that with beta1 I did not have to add the base path, I was just using "/" in the "All base paths for this site" textarea. However, with beta2 I had to add the base path. Can you please confirm that this is the way forward?
In #55 you had mentioned the below, so I guess that this configuration will be required going forward:
Also, just in case somebody has any ideas here, regarding the compatibility with the linkit module, I am using the latest linkit 2.x dev version #1221606: Linkit is on the input side and should not control how results are rendered which adds the language prefix and this results in pathologic not being able to alias the link properly. If I manually remove the language prefix from the link that linkit generates then this works fine with Pathologic.
Comment #81
Garrett Albright CreditAttribution: Garrett Albright commenteddimitriseng, if you didn't have to add the slash in beta 1 but now you do in beta 2, that's definitely a regression. Kinda frustrating, too, because I thought I had really nailed all that this time. I think I see what might have gone wrong… so much for my brilliant fix. I'll try to fix it again in beta 3.
idflood: I applied your patch; it may or may not be in Git or the most recent dev release by the time you read this (I'm about to fall asleep). But am I reading your code correctly in that it now completely ignores the language code of the content that's being filtered and just uses the LANGUAGE_NONE "language" for everything? And that really works?
Comment #82
jmones CreditAttribution: jmones commentedI've tested beta2 and it doesn't work for me for an image url inserted by tinymce.
The original url looks like:
/sites/default/files/image.png
And current beta2 converts it to:
http://domain/en/sites/default/files/image.png
I've used the following code as a quick hack.
Original code:
Modified code:
Comment #83
idflood CreditAttribution: idflood commented@Garrett Albright: Yes, it uses the language_none for everything. I'm not sure why it works better this way, I will see if I can add more language tests to pathologic.
Comment #84
idflood CreditAttribution: idflood commentedI've added a simple test for image file. There is one patch attached with only the new tests, the other one contains the tests and the fix.
Comment #85
fietserwinIn addition to #82, I can confirm that the current code still returns the wrong result for images.
Debugging down to the code that causes this I arrived at this function in locale.inc (locale module):
From this code it can be seen that Pathologic should not pass in NULL but a "language" object with an empty prefix property:
Notes:
Please also note that I do think that this is an error in core (locale module). I opened an issue in core for it: #1196606: url()/locale_language_url_rewrite_url(): language prefix should not be added to URL's pointing to existing resources. Please chime in there to get some support for it. I will write a patch if there is support for my view. In the meantime, this patch can still get into Pathologic. It won't bite, even if it gets solved in core eventually.
Comment #86
NaX CreditAttribution: NaX commentedThis same problem or similar came up with D6 early on in this issue. See Comment 25 & 28.
Comment #87
Garrett Albright CreditAttribution: Garrett Albright commentedfietserwin, in your test, is creating the node necessary? I see you use the path to it to do the actual test later, but wouldn't just using any path that would already be there in core (like fr/user or fr/node) suffice?
Secondly, there seems to be two issues here, if I understand correctly; one being that links to pages are problematic and one being that links to files are problematic. Am I correct? I'm kind of getting mixed up which posts/patches relate to which problem.
Third, thanks all for the bug reports and patches, but in the future, could you all make sure you're testing and patching against the HEAD of the branch and not a certain release? For example, the problem #82 reports should have been fixed in HEAD a while ago - reporting bugs in releases doesn't totally help me when they've likely been fixed for a while.
Four… okay, new release, with inspiration (though not direct patches) from this issue. Please test, then test the HEAD code, and report back about linking to pages in this issue. If linking to files still seems to be broken, could someone please create another issue about it so that we can keep things mentally separate a bit more? Thanks.
Comment #88
fietserwin#87: I'm bit confused about your remarks:
- What test of me do you mean?
- What I get from the comments since (more or less) #51, is that the only problem discussed here, is with links to existing resources in multilingual sites with prefix language negotiation. So I'm not sure what would be the other problem?
- My patch is against the latest dev:
But maybe you are right. This issue started in 2008. So we might better either create a issue summary detailing the current problem or we close this one and open separate detailed issues for every problem that anybody thinks that is still in the code.
Comment #89
colanYes, see my comment in #77.
Comment #90
fietserwinMy patch fails in other situations, namely when fields are untranslatale they get language code 'und', the code I was using to cater for existing resources. This means that the idea from #82 is not that bad. But I don't get the check on '/' (also considered local' setting should cater for that by also having a line with only /) and it will fail on index.php?q=... paths as index.php will exist...
I'm now looking for a way to cater all these situations.
Comment #91
fietserwinOK, a new patch that should cater for a lot more situations.
- For existing files, the query and fragment part are retained. This seems strange and unnecessary for images, but an existing file may also be an html file (help file, example file), thus with a fragment part and/or query part.
- Existing files now work in multi lingual situations.
- Drupal paths work in multi lingual situations (they already do, but didn't anymore with my previous patch)
- index.php/q=... works (already works, but didn't work with the proposal from #82).
Comment #92
dimitriseng CreditAttribution: dimitriseng commented@Garrett - Thanks for the new release. However, the "All base paths for this site" does not seem to be working for me with beta3, used to be working with beta2.
@fietserwin - Can you please provide #91 against beta3? Also, the patch seems to be type 0 and I cannot apply it using Eclipse (or maybe I am doing something wrong but I can apply others ok).
Comment #93
fietserwinBeta3 contains the same error I encountered with my patch and which I described in #90.
E.g:
- node/21 is of type basic page and has language en
- Field body of node type basic page is "not translatable" (this is the default since D7.3 or something like that, only when using entity translation this might be different).
- So all body fields will have language 'und', regardless the language of the node. (have a look in your database in table {field_data_body}.)
- The language code of the field is passed to the filter, not the language of the entity or even current page.
- So links in these body fields will be url()-ed with no language passed in.
- So links to Drupal paths fail as there is no language prefix (links to existing resources will work though....)
Rerun of the patch against beta3 attached. (I don't use git on projects that are not mine, so I make patches with a separate patch tool. Normally, they should apply though.)
And what I forgot to mention (it was already late yesterday):
In getting a working patch first, I did not copy the query parts massaging part. After that I did some tests: when using parse_str() you can not distinguish between ?a=&b=... and ?a&b=.... So why would you set it to NULL and not just leave it as it is? note that this also means if you run a http_build_query() after that, the result may be different form the original... (I'm not sure if the url rfc says something about this):
Comment #94
Garrett Albright CreditAttribution: Garrett Albright commentedMy bad, looks like it was idflood's patch that had the test.
If you're seeing anything by the packaging script, then that's not quite what I meant. What I mean is the HEAD of the master branch of the Git repo. But later you said you don't use Git on projects that aren't yours - care to enlighten me why?
That's interesting. I would think they'd be different in the same way that a NULL value and an empty string are different in PHP. I'm going to look into that.
Comment #95
fietserwin#94: thanks for your reaction.
I prefer to keep dev and HEAD equal. Locally they may be different, but on drupal.org they are equal. However, I am aware that there are situations where that may not be preferred.
But anyway, your remark made me think about the why? Is it less work? I guess that as dev versions cannot yet be installed via the Drupal update interface, installing it via a dev package is as much work as would installing it via a git repo be. So I think I better update my working habits here (that come from the cvs era and where I could not even bother having a cvs account).
Comment #96
winklet CreditAttribution: winklet commentedWhy can't I apply any of these patches? I'm using Tortoise SVN and it keeps rejecting the new code. help! I am a newbie!
Comment #97
Garrett Albright CreditAttribution: Garrett Albright commentedwinklet, the Drupal community uses Git, not SVN. I think there's a version of Tortoise that works with Git, though I'm not sure.
Comment #98
hass CreditAttribution: hass commentedI still have this issue with latest D7-1.4. After I entered a "/" in
[pathologic][settings][local_paths]
field all URLs tosites
folder have been destroyed.Comment #99
hles CreditAttribution: hles commentedI also ran into this issue, using the configuration: "/" in [pathologic][settings][local_paths].
But I downloaded the latest dev before doing some debugging and it fixed it. So what's actually the state of this issue ?
Comment #100
robertom CreditAttribution: robertom commentedSorry for my bad english...
I have problems with link on node translated with i18n module...
@hles: you use i18n content translation or entity_translation?
The patch on #93 doesn't apply cleanly on 7.x-2.x HEAD.
for fix my problem, I've created a quick patch, but with a different approach... I don't have tested this patch on depth, but I want to show up this approach for some feedback
@Garrett Albright: sorry... for now there isn't tests. I hope to make it asap (but I'm a bit newbie on this :P )
Comment #101
idflood CreditAttribution: idflood commented@robertom: The patch in #70 contains only a test. It may be enough but I bet more tests can be made.
Comment #102
January CreditAttribution: January commentedsame issue (multilanguage did add a /en/ in the source path) with drupal 7.12 and pathologic 7.1, but got fixed with update of pathologic to 7.2.
thanks a lot for the module!!!
keep up the great work!
Comment #103
mfgr CreditAttribution: mfgr commentedHmmm.... Having implemented #100 on my website, I get this error:
or
Seems like this patch is exhausting memory limits but I don't know why or how.
Comment #104
rp7 CreditAttribution: rp7 commentedSorry for re-opening this, but I'm not 100% convinced linking to files is fixed.
If I link to a file in my files folder (eg. sites/default/files), the langcode will be added, rendering the link invalid. For example:
<a href="http://www.mysite.com/sites/default/files/myfile.zip">download my file</a>
becomes
<a href="http://www.mysite.com/nl/sites/default/files/myfile.zip">download my file</a>
Tested this on a clean install, D7.15 & Pathologic 7.x-2.1.
Comment #105
rp7 CreditAttribution: rp7 commentedI revoke what I last said. I missed the file_exists(realpath($parts['path'])) check, I was obviously testing without actually having the physical files in place. My mistake.
Comment #106
Garrett Albright CreditAttribution: Garrett Albright commentedResetting version value.
mfgr, out-of-memory errors can be caused many ways. If you're fairly certain that Pathologic is at fault, please create a new issue for the problem. This one should only be used for multilingual-related problems.
Comment #108
Drupa1ish CreditAttribution: Drupa1ish commentedThe link to the referred node is correctly setup, but it doesn't change with language ( need clear cache every time). It keeps the value of the language last time node was saved.
Use case:
http://et.debu.eu/en/pathologic-parent-alias links to http://et.debu.eu/en/pathologic-child-alias
But italian version, http://et.debu.eu/it/pathologic-genitore-alias still links to http://et.debu.eu/en/pathologic-child-alias ( instead for http://et.debu.eu/it/pathologic-bambino-alias).
Comment #109
Garrett Albright CreditAttribution: Garrett Albright commentedEuroDomenii, I logged into your site and edited the "genitore" node so that it linked to "node/8" instead of "/node/8," and now it seems to properly link to the "bambino" page with no problems. Note that Pathologic by default won't "see" paths that begin with a slash like that - you'll need to either use relative paths without a beginning slash in your content, or configure Pathologic to work with paths that begin with a slash. See the WYSIWYG editor compatibility section of the documentation for more info.
Comment #110
Garrett Albright CreditAttribution: Garrett Albright commentedReclosing.
Comment #111
Drupa1ish CreditAttribution: Drupa1ish commentedThank you for checking the issue. Unfortunately, the bug is well hidden. The problem is that the link label is changing correctly ( according to the language), but the link it self doesn't.
In our case:
1) For italian lanugage( last saved): http://et.debu.eu/it/pathologic-genitore-alias main article, link label correct Pathologic bambino alias and link itself http://et.debu.eu/it/pathologic-child-alias
2) For english language : http://et.debu.eu/en/pathologic-parent-alias main article, link label correct Pathologic child alias, but link itself incorrect http://et.debu.eu/it/pathologic-child-alias ( instead of http://et.debu.eu/en/pathologic-child-alias)
Comment #112
betz CreditAttribution: betz commentedI can confirm the same problem.
Instead of using sufix's i use a domain name per language.
The text is fine, only the link uses the link of the language when saved.
Also, when you save the text format settings, the first language you open gets used on all languages.
So this is a caching problem...
Comment #113
apemantus CreditAttribution: apemantus commentedYes, this is an issue with caching. For most sites, caching the content filter is going to be preferable, although I guess pathologic could offer it as part of its configuration.
However, it's pretty easy to workaround. In Drupal 6 you just had to create a custom filter that just had "CACHE" set to false, and add this alongside pathologic.
In D7, it's probably even easier just to add:
(Untested as I haven't yet added pathologic to a D7 site)
Comment #114
reekris CreditAttribution: reekris commentedI had the same problem as #111. After some backtracing I found that drupal automatically loads and caches the translations of a node when viewed. This means that the first node being visited after flushing the cache will load and cache all language versions of that node.
Since you are visiting the node in a specific language, pathologic won't work when trying to generate aliases for the translated versions, since they don't match the current language.
The module responsible for loading and consequenlty cache the translated nodes is the Translation core module. The specific function is translation_node_view. It implements hook_view to create links for the translated versions of a node when viewed. There is an option to disable these links in the translation settings, but this hook will run anyway.
Since I don't need these links, my solution is to remove this hook. I don't want to hack core, so instead I tried 'unhooking' it in my own module by adding the following code:
After clearing the cache and viewing a node, translations of that nodes are no longer being loaded and cached when they shouldn't and they get the correct links generated by Pathologic when viewed.
Comment #115
Garrett Albright CreditAttribution: Garrett Albright commentedreekris, that's very interesting. Do you know what might be happening there? That function doesn't seem to be altering the node in any way that Pathologic would care about, so I suppose it's altering the global state somehow…?
Comment #116
reekris CreditAttribution: reekris commentedI'm not sure. But it's responsible for loading the translated versions of a node to be able to get the language links to them (It happens in the translation core module, translation_language_switch_links_alter. It does a node_load on translated nodes, which also causes them to be cached.
I believe the problem is that when a node is loaded with a language that isn't the current language, Pathologic will not generate the correct aliases for that node. As the node is being cached with the wrong aliases, it will stay that way when you view it. I tried the following on my site which I believe shows that this is the case.
I have a site with two languages, English and Polish. I have a node in English with a nid of 5, which also has a polish translation.
I clear the cache and then go to the English node, but with polish as the current language, like example.com/pl/node/5.
Pathologic will not generate the correct alias for "node/" links in the body field.
I think this is what happens when translation_node_view loads all the translated nodes. The current language is Polish while it's loading the english node translation, which caches the nodes with the wrong aliases generated.
Comment #117
Jason Dean CreditAttribution: Jason Dean commentedI'm in a similar situation to the original poster:
On a clean Drupal 7 install, using:
In the body field of a node, I make a link to another node:
English body:
Click <a href="/node/1">here</a>
German body:
Click <a href="/node/1">hier</a>
So if a visitor is viewing the page in German, it should link to mysite/de/node/1
But this only happens if after I've edited and saved the German body. Then it links to mysite/de/node/1 whatever language I view the site in. If I edit the English body and save, it links to mysite/node/1 whatever the site language. So whatever the last edit language was, it seems to be applied to all translations of the node fields.
I have caching disabled.
Some comments above (e.g. #53) suggest that this issue is fixed in 7.x-2.x branch, but it just isn't happening for me?
Thanks
Comment #118
hass CreditAttribution: hass commentedTry DEV
Comment #119
Jason Dean CreditAttribution: Jason Dean commentedLatest dev produces the same results described in #117
Comment #120
dieppon CreditAttribution: dieppon commentedAs today, Dev and 2.11 has the same code but I still getting the same error as in #111.
Comment #121
djschoone CreditAttribution: djschoone commentedJust tested with 7.2.11 (which is the same as dev atm) and doesn't work.
How to replicate?
Go to a node edit page from an English page (in my case) while being using the Dutch language (EN is non-prefixed, NL is) so my url looks like nl/node/5/edit
I have some relative and absolute internal links. If I save the page, all of these links (while the language of the page is set to English!) are rewritten to the nl/ part
If anyone has a suggestion where and how to fix, I can test it right away!
Comment #122
Garrett Albright CreditAttribution: Garrett Albright commentedThanks for the walk-through, djschoone.
Are you familiar with applying patches? If so, could you give the attached a try?
Comment #123
djschoone CreditAttribution: djschoone commentedYep. No problem. Will give it a try and let you now. I have been debugging myself, but hadn't found the solution yet.
Comment #124
djschoone CreditAttribution: djschoone commentedTested it. What it does is removing all language prefixes. Even if it applies to have a language prefix in the URL.
I think the biggest issue here is that we need to know in what language the linked node is written in, so we can add the right prefix for that language (this applies when linking via internal links - aliases or nid reference)
Comment #125
djschoone CreditAttribution: djschoone commentedDoes somebody have an idea where to pick-up in the process of building the link? We have to fetch the right language for the linked node and add it there. This can be found on various places, so will be quite hard. Not for the aliases (pathauto) of plain nid / tid's, but especially all those other modules (ie views) who are able to claim 'paths'.
Comment #126
SebCorbin CreditAttribution: SebCorbin commentedI used this to solve #117
Comment #127
Garrett Albright CreditAttribution: Garrett Albright commentedSebCorbin,
$settings['langcode']
contains the language code for the field, if it's translatable, but that may not match the language code of the content you're linking to. So that code may work for your case and others', but it's not globally applicable.Comment #128
osopolarPeople who experience problems with wrong file-paths due to the modules intention of path-translation and the need of translation in content may check out the following issue: #2329523: Opt-out from path translation.
Comment #129
fietserwinLike #117 and #126, I discovered that in combination with entity translation, results may indeed be incorrect. Apparently, when we have a filtered text field in multiple languages, the hook_filter() is called (and the result cached) for all languages at once upon first usage in one of that languages.
Example:
- I have a node in Dutch and English.
- I view the node in Dutch.
- The text fields are passed through hook_filter for both the Dutch and English language
Assume that in the text, I have a link like node/123 (thus to another multi-lingual node, having different aliases per language):
- This path does not contain a language part, thus no language gets passed to url() (lines 359+ and line 420).
- In the dutch text, this gets correctly aliased to nl/{dutch-alias-of-node-123}.
- In the English text this gets also, but incorrectly, aliased to nl/{dutch-alias-of-node-123}.
The solution of #126, to explicitly add the language code of the text we are filtering is correct as we cannot assume the current language to be the language of the text being filtered.
I made a patch for this against the current dev version. Please review and, eventually, commit.
Comment #130
Garrett Albright CreditAttribution: Garrett Albright commentedHmm. Has anyone else tested fietserwin's patch? I think I'm starting to understand why it's better than the current behavior, but I'm not sure if it might have unexpected repercussions.
Might have to just do the whole "patch and release it and then wait for people to start complaining" thing.
Comment #131
mgiffordWe're going to be testing it soon and using it in production. We're having problems with the current behavior in a multilingual site.
Comment #132
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, please let me know how it goes.
Comment #133
aspilicious CreditAttribution: aspilicious commented#129 solved all issues described by fietserwin
Comment #134
baso CreditAttribution: baso commentedI had the same problem as described in #129 by fietserwin and can confirm that his patch works for my multilingual site.
Comment #135
k.minkov CreditAttribution: k.minkov commentedWe faced the following problem with multilingual site and version 7.x-2.12. The site is in english and danish as the danish is default and is without prefix, english is using /en prefix.
In the body field of a node there are links with danish aliases to some danish content. When visiting the node and current language is english these urls got prefixed with /en which is breaking them.
The attached patch is fixing this issue.
Comment #136
.bert CreditAttribution: .bert commentedThe patch in 129 did not completely resolve the issue, as we still had pages rendering incorrect links. These were pages where only one language was input. For example, the English content was input (site uses no language prefix for English), but when the French page is viewed first after a cache flush, the links on both versions contained the French prefix.
Adding patch 135 appears to have fixed the issue completely. We are using both patches applied to 7.x-2.12. Thanks for the patches guys.
Comment #137
dmsmidtHere is a combined patch (#136 + #129) against 2.x-dev. (Only works for translatable fields I think).
Note the patches as proposed until now break the normal (faulty) auto prefixing for fields on enitities not using the entity translation module (e.g. regular D7 multilingual nodes).
So prefixes are not automatically added anymore. This is because we don't pass NULL as language parameter anymore to the url() function, but a language object with language undefined and an empty prefix.
Comment #138
dmsmidtI reworked patch #137 to allow auto prefixing again for non-entity_translation enabled fields.
So it now works again for fields with LANGUAGE_NONE, but belonging to (for example) a node with a language set.
The patch prevents some of the problems mentioned in #116.
/node/" where the prefix language and the language of the node are different. This is fixed now.I don't see translation_node_view() loading all translated nodes.
But, I could reproduce the problem of visiting the url "
Comment #139
Garrett Albright CreditAttribution: Garrett Albright as a volunteer commentedIt looks like the patch that dmsmidt is providing is targeting the same bug as reported in #2415771: Trouble with Entity Translation and embedded node links. Does anyone think otherwise?
Comment #140
dmsmidtHi Garrett,
The problem looks similar, but note that my addition is for multilingual nodes NOT using Enitity Translation.
However it should also work for nodes with Entity Translation (was fixed in #136 + #129).
Could you see if this patch solves the issue?
Maybe we can use #2415771: Trouble with Entity Translation and embedded node links to develop tests to show the problem, and this patch to fix it?
Comment #141
dmsmidtI'm sorry but the supplied patch earlier is not working in combination with i18n menu translations (Noted earlier in #44).
Always using arg(1) to get the node language when we are on a node page is a wrong assumption. Because i18n menu also loads all node translations for menu items.
I don't see a quick way out to reliably get the text language when not using the entitytranslation module, since in the filter process we don't have any context info (about for example which entity a field belongs to).
Comment #142
Garrett Albright CreditAttribution: Garrett Albright as a volunteer commentedThanks for the recent updates, all. I'm trying to dedicate some time this week to finally updating Pathologic; I'll try to have another look at multilingual issues tomorrow. Fortunately my company has had me working with an i18n-heavy project recently, so I know quite a bit more about how entity translation should work than I used to.
Regards;
-- Your beloved lazy module maintainer
Comment #143
holyfire CreditAttribution: holyfire commented@Garrett Albright, just wanted to follow up and see if you had made any additional progress on this since #142. We recently ran into an issue where we're having issues with multilingual URL handling in body text, basically /es is being injected when it's not needed and we're stuck without a contrib based solution. We're going to basically change the editor to exclude pathologic on pages where we run into this type of issue going forward, which is not ideal. Thanks for all your work on this...
Comment #144
Alina Basarabeanu CreditAttribution: Alina Basarabeanu commentedUpdate the patch to work with 3.x-dev
Comment #145
Alina Basarabeanu CreditAttribution: Alina Basarabeanu commentedUpdate the patch to work with 3.x-dev and latest commit
Comment #146
mikgreen CreditAttribution: mikgreen commentedI've had issues with previous patch. The main one in our case is, if the the link language is not determined, then we fallback to default site language (we have a site with default language that has no path prefix).
Comment #147
mikgreen CreditAttribution: mikgreen commentedComment #148
mikgreen CreditAttribution: mikgreen commentedFixed small copy-paste bug.
Comment #149
mikgreen CreditAttribution: mikgreen commentedA simpler version.
I think it is established that link language should not be determined by current page language.
So I'm removing parts that do that in this patch.
However that might be different in each case.
Maybe there needs to be setting "fall back to current language" or "fallback to default language" when link language is not determined?
Comment #150
dalinPatch seems to work great, but it needs tests. Given that a site is configured to have 2 languages (one without a path prefix), then I think we need tests for all combinations of the following:
I recommend keeping this issue simple and creating a follow-up for those less common needs.
Also, if this ticket isn't resolved soon we should rewrite the description, since I think we've evolved to be a bit different to the original request.
Comment #151
tondeuse CreditAttribution: tondeuse commentedMy scenario is the following :
I have the feeling that this patch may be incomplete at the moment, as is does not seem to take the entity translation model into account.