[#13537] - Adding the Multilanguage Associations Manager
- Fixed in Code Base
- 17 Jan 2017
- Medium
- Build: staging
- # 13537
- Diff
- rdeutz:com_associations_rewrite_merge
User tests: Successful: Unsuccessful:
Executive summary
This PR is a partial rewrite of the com_associations component based ion the work done in the Google Summer of Code Project "Improved Multilingual" (Repo: https://github.com/joomla-projects/gsoc16_improved-multi-lingual)
Background information
The original concept made a lot of assumptions about fields and extensions and instantiated extensions models to get information about the internal structure. This concept comes with two problems:
- Guessing can be wrong :-)
- Instantiate a model can end up in fatal errors and a not working Website when the extension has a bug.
I removed the guess and model instantiating and replaced it with a help class for extensions. This helper class provides all the needed information.
Backwards compatibility
It is a new function so no problem here
Translation impact
Two new language files for com_associations and one new language for any core extension that supports associations.
Testing instruction
- clone or get a copy of the staging branch
- setup a multilingual website
- Apply patch
- discover install
You will now find a new extension under components.
The select box allows to chose an item type.
When you have chosen a type and language, you can see your articles.
Click on an article (reference) and you will see the reference article on the left side. On the right side you can chose a translation target and translate your article.
If you click on the available translation you get directly the view with two articles side by side.
Developer documentation
If your extension support association and you will make your extension available in the Associations Manager you have to provide a helper class (we have examples for com_content, com_contact, com_newsfeeds, com_menus, please look at the example implementation for inspiration :-))
You need to create a file "associations.php" in your component admin helper directory. If your component is names foobar the help class must be named as "FoobarAssociationsHelper" and it must extend "JAssociationExtensionHelper".
Define three protected vars:
$extension = 'com_foobar';
$itemTypes = array('your_itemname', 'category');
$associationsSupport = true;
Define three public functions:
public function getAssociations($typeName, $id)
This function provides an interface the "JLanguageAssociations::getAssociations" and returns an array of associated items
public function getItem($typeName, $id)
This function should return a JTable Object for the type and id. Don't forget something like "JTable::addIncludePath(DIR . '/../tables')" so that the class can be found
public function getType($typeName = '')
Here you set up information per type, the function returns an array:
array(
'fields' => $fields,
'support' => $support,
'tables' => $tables,
'joins' => $joins,
'title' => $title
);
For fields and support we have a template function that set defaults so the you only have to overwrite what is different in your extension. Make sure that $fields['title'] and $fields['state'] are set right.
We need to write some documentation in JDocs but I think that here should be enough as a start.
Open Issues
- Ordering not great
- Deal with checkout items
- Extensions with multiple use of categories (seems a theoretical problem, because we couldn't find an extension using it)
Final words
I would like to says thanks to the GSOC project members you did most of the work.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_contact com_content com_menus com_newsfeeds Language & Strings |
This is a very handy functionality, but should this not being built into the article manager itself, when editing an article? On a first glance it will be difficult to understand why the compare editor is on a completely different place, despite that the association is managed in the article itself.
this does not only deals with articles. it is a general interface concerning all associations. here already implemented for core extensions, i.e. articles, menu items, contacts, newsfeeds, and will be for weblinks. we already can deal, article per article, generally speaking with all core extensions, item per item. com_associations is centralising all these (including 3pd if they set it) in a unique interface.
| Labels |
Added:
?
?
?
|
||
From developer point of view you are absolutely right and all makes sense. But for the end user I think it would be more convenient when you don't have to
- close the article edit view
- switch to the associations component
- select the type
- select the article
- select the language
- click on the article
- select the target language
before the compare view opens.
Mostly you want to do that when you edit the article directly. Probably a button beside the "Save as copy" button would make sense to switch to the compare view. But I'm more of a developer than UX person so I think would be nice to have some input from UX people as well.
This is a very handy functionality, but should this not being built into the article manager itself, when editing an article? On a first glance it will be difficult to understand why the compare editor is on a completely different place, despite that the association is managed in the article itself.
@laoneo IMHO, if this componet exist it would be relatively straigh forward to integrate it in the "Associations" Tab "Edit" buttons (or something like it) in the future (excluding ACL checks, basicly should be opening the modal with the com_associations URI, instead of edit URI). Here:
If I'm not mistaken you'd still be able to set associations from within the article edit view, it just seems like this mainly creates an alternative workflow to set associations and a way to have the content from two associated items open side-by-side instead of needing modals or separate windows. Just from the screenshots and what little I know of associations since I get chastised whenever I touch content on the one multilingual site I manage I don't see any UX issues with this at the moment.
It is not only extremely handy to use it when you create a multilingual site: prepare your site in one language and then do all associations (it includes also create a new one or change the assoc to another item) from the original reference item, but also, after on when you change some stuff in the "base" item and want to modify the assoc content (what we call the Target item).
It took me a few minutes to make an association helper for sermonspeaker:
@Bakual
associations.php.zip
(Still have an error in side by side with this file though)
+++ a new ini string
COM_SERMONSPEAKER_CATEGORIES="Categories"
@Bakual
Corrected the error in the sermonspeaker helper
associations.php.zip
@infograf768 Didn't have yet time t test anything here, but thanks. I've already added it to my repo
https://github.com/Bakual/SermonSpeaker/blob/master/com_sermonspeaker/admin/helpers/associations.php
I have tested this item
Ok for me.
But please consider to change the "Clear" button in the Target side in "Delete Associations" to avoid confusion and help in the translation procedure.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13537.
Here is a demo of the checked_out issue.
The item concerned has been checked out by another user.
The user editing has no com_checkin manage permission.
I have tested this item
Small thing:
In the "Select Target" modal, the tooltips for the search fields above are hidden behind the modal header. In other similar modals we set the tooltips to go below the field and not on top.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13537.
For the Select Target Modal tooltip, change in /administrator/components/com_associations/views/associations/tmpl/modal.php
JHtml::_('bootstrap.tooltip');
to
JHtml::_('bootstrap.tooltip', '.hasTooltip', array('placement' => 'bottom'));
| Labels |
Added:
?
|
||
Created helper for weblinks.
joomla-extensions/weblinks#294
@rdeutz @infograf768 it seems this PR misses the update (extension + asset) and installation part (extension + asset).
@andrepereiradasilva yes I am working on it just at this moment :-)
| Category | Administration com_contact com_content com_menus com_newsfeeds Language & Strings | ⇒ | Administration com_admin SQL Postgresql com_contact com_content com_menus com_newsfeeds Language & Strings |
| Category | Administration com_contact com_content com_menus com_newsfeeds Language & Strings com_admin SQL Postgresql | ⇒ | Repository Administration com_admin SQL Postgresql |
| Labels |
Removed:
?
|
||
| Category | Administration com_admin SQL Postgresql Repository | ⇒ | Administration com_admin SQL Postgresql com_contact com_content com_menus com_newsfeeds Language & Strings |
| Labels |
Added:
?
|
||
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-01-17 11:46:48 |
| Closed_By | ⇒ | wilsonge |
Good work to everyone involved. Especially @rdeutz @infograf768 and especially @jreys for getting this started with your gsoc work :)
Thanks guys! @rdeutz @infograf768 @alikon @andrepereiradasilva and @jreys
Will the side-by-side view be available when editing an article on the front-end?
Will the side-by-side view be available when editing an article on the front-end?
Not in 3.7.0
I am not aware of anybody working on a frontend Interface.
Hi guys,
I have a question, you wrote:
- "When you have chosen a type and language, you can see your articles."
- "Click on an article (reference) and you will see the reference article on the left side. On the right side you can chose a translation target and translate your article."
- "If you click on the available translation you get directly the view with two articles side by side."
Please, the "available translation" availability depend on... ?
Depend on the default "Language > Content: Language Tag creation" ?!?
To really be able to manage sites multilanguage sites (quickly and simply) I think 3 things are a must:
1 - A front-end interface, on normal sites is unthinkable to give translators an administrator access. This front-end interface should have an ACL based on language/s assigned to the user (showing only those languages)
2 - A layout more simple as possible. This is way I want put in evidence the Speedy Translate extension by Solidres. They found some solutions that in my opinion should be a need on joomla Multilanguage. In first of all I want put in evidence the "Inline Translation" feature. Click on a flag is 1 click, while click on a selector, choose, and select are "3 clicks".
3 - Last but not least, an article a lot of time have to be ready quaickly and it is hard to have all translated well soon. So, a "pre" - "auto-populate" button can be a solution (where clicking all the enabled languages are populated into the articles), as it is running (one by one) the Translater CKEditor plugin .
Many Thanks to all for this great new feature...
@joomleb This is a closed (merged) PR and thus doesn't get much attention. You would have to create a new issue if you have found a real issue. If you just need assistance with this new feature, feel free to use the forums (http://forum.joomla.org/)
We do need indeed some inpt to solve the checkedout.
And also the ACL: do we let edit/create associations for items where one has no create/edit ACL, on individual as well as extension level.