I'm currently looking at the way in which the prefix is added to pages which are generated by views, and to be honest I'm confused as to why the current approach has been taken.

The path prefix which is added to pages is determined by the prefix of the administration path to the view. This means that in order to have a 'jp' prefix I have to design the view in Japanese. Worse than that, if I go on to modify the view while browsing in English I end up with another URL being defined without the prefix.

I can see this happening a lot - I'll want to make a modification to a Japanese view so I'll browse to it via the views list, make the mod, save, and in the process accidentally create an English url for a page which contains no English content.

Even worse, there's no way of deleting the English URL once it's been created without deleting the view and starting again, which would naturally affect the legitimate Japanese page. The URL can be modified, but only to something else which doesn't have a prefix (or has an incorrect one). The view can't be saved if the URL is deleted. Please correct me if I'm wrong, but I can't see a way of deleting such erroneously-generated URLs.

Surely a better solution would be to have the target language of the URL selectable in the same way that the number of items per page is selectable. This would allow the administrator to work in any language while still having full control over the output page's URL / language.

Comments

RichieRich’s picture

RichieRich commented

Hold on a second...I seem to have misunderstood the way in which the URLs are being generated. On inspection it seems that all my views are accessible both with and without the 'jp' prefix irrespective of whether or not I've viewed the view admin in Japanese.

I guess that the feature request remains the same however - can something be added to the view which would allow administrators to specify the target language of the output URL?

Currently a language can be selected when filtering, but the resultant pages are still accessible via multiple URLs.

Am I missing something? Please put me in my place if I am.

Thanks, Richard

gterez’s picture

gterez commented

Not a solution, but a workaround that may help you for now: use the Insert View module to inject views in normal nodes where you are free to set your own path (you can even supply attributes).

RichieRich’s picture

RichieRich commented

Thank's gterez. That's true, but it's pretty easy to insert views programatically anyway - I'm already doing this with a few pages on my site. However, if I want to inherit a default view and insert it I either have to create a page, which I'd avoid due to the problem listed above, or a block. Inserting a block would be okay, but it means that I'll essentially be creating blocks which I simply don't require just to work around the way in which paths are being defined.

However, I was doing some reading online and it seems that inserting views is frequently recommending when working with the Internationalization module. Why? Surely it should simply be a case of allowing the admin to decide what the target language(s) should be. What's the point of creating an output URL for a view which is presenting nodes or node previews in a different language?

jose reyero’s picture

jose reyero commented
Status: Active » Closed (won't fix)

This looks like a feature request for Views, please post to the right module and reopen.