Anwiki CMS

Anwiki CMS : the first wiki/CMS dedicated to multilingual contents
| Tasklist |

FS#73 - Allow "translation" of images

Attached to Project: Anwiki CMS
Opened by Wladimir Palant (trev) - Wednesday, 10 March 2010, 09:24 GMT
Task Type Feature Request
Category Core
Status Unconfirmed
Assigned To No-one
Operating System All
Severity High
Priority Normal
Reported Version Anwiki 0.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


I am using different images for different languages on my site. As it is now, doing this with Anwiki is problematic - images cannot be turned into Anwiki pages, consequently you cannot have the image link auto-adapted depending on language. For now my work-around is a special content type for images plus an override for view action to allow output of raw images (both in the attached ZIP file). Originally I thought about keeping HTML output for the view action and displaying the raw image in a new action but that makes URLs more verbose and caching is more difficult. The downside is that you cannot go directly into translation mode from fr/images/test.png - you have to add "?a=translate" manually. The other problem with this content type is that you have to enter image data in base64 format, uploading a file directly isn't possible.

Oh, and I had to modify $asREGEXP_LINKS in class_page.php as well - it has to check src attribute.
This task depends upon

Comment by anw (anw) - Wednesday, 10 March 2010, 23:26 GMT
Yes, files uploading is something which absolutely needs to be added to Anwiki.
A new attribute type "file" will be supported for contentclasses (with options to restrict size/filename), so that you won't have to copy/paste the image data in base64 format.
It would also give better performances to not store the file data directly into the "anw_page" table - even if cached, it's weird to store image data into structured XML :-)
It may also slow down the AutoSync algorithm when updating the field value...
We may store the file data into a dedicated blobs table + cache system, or maybe directly on the filesystem...
The import/export script will be updated to generate an archive for including these files. Also for the translation screen, which should allow uploading "translated" files - when file attribute is translatable.

Anyway thanks for your contentclass suggestion, it's a nice workaround for managing translations of images - at least a temporarily solution!
Have a look to attached file - I added a parameter to only output image data when giving parameter "?rawimg=1" (had to implement AnwCachedOutputKeyDynamic on the contentclass for caching issues). That way, action_view is not broken - this action also doesn't need anymore to be overriden.

It looks also a bit weird to manually hack the "src" attribute for linking the image by URL, and getting it analyzed with $asREGEXP_LINKS.
Maybe an abstraction "tag" such as <anwimg name="myimage"/>, which would automatically resolve appropriate image translation by its name and link with the ?rawimg=1 parameter, would be more appropriated.
You an "easily" implement this with a plugin based on vhook_outputhtml_clean_body_html (for transforming content value before caching, so that transformation doesn't affect attribute value, and only affects its rendering). Have a look to the plugin_smilies or plugin_commontags... don't hesitate for any question!

I can't give ETA for file upload attribute, as it will have various impacts (import/export, translation form, file or database structure...).
I also think we need a more flexible solution for quickly "attaching" files directly to a specific content, without leaving the edition form of the main content. So I'd prefer to be sure of an optimal solution before implementing it. Suggestions are welcome!
Comment by anw (anw) - Wednesday, 10 March 2010, 23:28 GMT
Oops, I forgot a debug trace on line 36... (print "!")
Comment by anw (anw) - Wednesday, 10 March 2010, 23:33 GMT
Ah, the 2 plugins I mentionned are "unofficial" and not released. They can be found on SVN:
Comment by Wladimir Palant (trev) - Thursday, 11 March 2010, 07:54 GMT
I'm less worried about performance because I don't plan to run PHP for users who aren't logged in - the current version of the site uses a "cache" built of static files already, same will be done here. This is also one reason why I prefer having images display with undecorated URLs.

As to <anwimg> tag, I have been also thinking about doing something like that - to have the alt attribute generated automatically from image title. Ideally, width and height attributes would also be generated automatically. Using vhook_outputhtml_run_body will be necessary then because the image can change independently of the page (as I said, I'm not very worried about performance). But my current work-around will do for now.
Comment by Wladimir Palant (trev) - Tuesday, 07 September 2010, 08:08 GMT
Attaching current version of my add-on, it no longer relies on hacking Anwiki source code. The raw output is produced by the new "show" action. The "view" action on the other hand still shows the menu, this makes things easier. In addition to the attached files I use the following code in vhook_outputhtml_run_body to bind image tags and add ?a=show automatically:

// Bind images to the correct target
$sHtml = preg_replace_callback('/(<img\b[^<>]*\ssrc=")([^"]+)(")/', array(&$this, 'bindImage'), $sHtml);


private function bindImage($matches)
$sLink = $matches[2];
if (strstr($sLink, '://') || substr($sLink,0,1) == '#' || substr($sLink,0,1) == '/' || !AnwPage::isValidPageName($sLink))
return $matches[0];

$oPageTarget = AnwPageByName::getByNameOrSecondChance($sLink);
if (!$oPageTarget)
return $matches[0];

$sPreferedLang = $this->oPage->getLang();
$oPageTarget = $oPageTarget->getPageGroup()->getPreferedPage($sPreferedLang);

$sLinkTarget = AnwUtils::link($oPageTarget->getName(), "show");
return $matches[1] . $sLinkTarget . $matches[3];

The way the action connects to the content class could be improved of course. Translators still see raw base64-encoded string - I would like to eventually use the File API ( and btoa() to encode a file on the client side if browsers that support it.
Comment by rafit (rafit) - Wednesday, 01 February 2012, 00:41 GMT
Maybe it's an old solution, but it is very interesting and it is what I need for my website - but I don't know how to use it.

I downloaded last, installed. Now I have a test image: "/pl/test.png" and it translation "/en/test.png". I can see two different images:

Then I found vhook_outputhtml_run_body in /sources/classes/plugin/class_plugin.php (you wrote "Attaching current version of my add-on, it no longer relies on hacking Anwiki source code." - how to do that mod without hacking sources?)
I changed function to:

protected function vhook_outputhtml_run_body($sHtml){
// Bind images to the correct target
$sHtml = preg_replace_callback('/(<img\b[^<>]*\ssrc=")([^"]+)(")/', array(&$this, 'bindImage'), $sHtml);
return $sHtml;

of course i added bindImage function before.

But then I get no effect. I inserted my test image into page as:

<img src="/pl/test.png"\> - no image
<img src="/pl/test.png?a=show"\> - i get an image, but no changes when I change page translation.

What I do wrong? How to use this extension?
Comment by anw (anw) - Friday, 10 February 2012, 00:18 GMT
Sorry for the downtime...

There was something missing in the plugin to retrieve current page, luckily we can use another hook to get it.
I published an addon here and will add it to the download page:

@trev: is the "show" action really needed or better than output directly from the contentclass?
If you look to my uploaded version, we don't need a dedicate action, just using a GET parameter and reusing the 'view' action.
Comment by Wladimir Palant (trev) - Friday, 10 February 2012, 14:53 GMT
The "show" action is necessary if you want to edit/translate images - otherwise all you get is a raw image and you have to add ?a=translate to the URL manually.
Comment by anw (anw) - Friday, 10 February 2012, 20:54 GMT
With last version uploaded, it should work exactly same without needing additional action, thanks to an additional parameter processed in toHtml() which is called from view action:
- /pl/test.png?a=view -> standard output (<img src="/pl/test.png?a=view&show=1"/>) - like the show action
- /pl/test.png?a=view&show=1 -> raw output

It's just to get less code to maintain and less things to configure