absolutely unaffordable to pay the price of being editing a term and to edit its translation (keeping synch between terms translations) just a link to the translate interface be provided
from there the translator have to navigate to search tab, then choose a language, the group taxonomy, type into the search box and get surprised when suddently he/she finds out that there are a lot of strings containing that word, but a wisely user knows he/she is only looking for unstranslated strings and saves the day
UNLESS he/she is looking for an unstranslated ENGLISH string, which won't get support from any search (until now) then the only option would be waiting for a patch to get committed #348575: Incorrect languages shown for translation status in locale search results (plus tests)
Here I provide some improvement to this lack of support for localize terms translations
PS: I'm wondering if it would be better to provide it in a "Translation" tab (local task) but in a fieldset seems to be more practical for reviewing, since translations are at plain sight then any out of date synch would be quickly detected
Comment | File | Size | Author |
---|---|---|---|
#4 | 2009-09-16 improve_localize_terms_support.patch | 5.09 KB | arhak |
#4 | i18ntaxonomy_localize_term.png | 30.9 KB | arhak |
#1 | 578360-patch1-before.png | 11.4 KB | matkeane |
#1 | 578360-patch1-after.png | 14.29 KB | matkeane |
2009-09-15 improve_localize_terms_support.patch | 5.68 KB | arhak |
Comments
Comment #1
matkeane CreditAttribution: matkeane commentedHi,
I've just tested this patch against the latest dev release (should I have run it against 6.x-1.1?). The last hunk wouldn't apply automatically, so I added that manually. I've attached a couple of before/after screenshots to try and make the changes in this patch clearer.
When editing a taxonomy term, a list of the translations (and any missing ones) is shown below the term name and description, which means it's easy to see the translation status in one place, which I like.
For missing translation strings, a link is provided to the translation admin pages, but when I tested it, the links only pointed to '/admin/build/translate/edit/' - the 'Translate interface' page. Ideally, the links would point straight to the relevant string translation edit form and, looking at the code, it looks like they are intended to do just that. I guess that, for some reason, the $lid wasn't making it through to the link...
This is a nice, simple improvement to the UI for translating taxonomy terms, so if we can identify why the links to the translation form weren't working properly, I think this would make a very useful addition.
[Edit] I just tried the patch against 6.x-1.1, and it applies cleanly (with CVS just moaning about the CR line feeds), but the problem with the translation links persists.
Comment #2
arhak CreditAttribution: arhak commented@#1 the whys:
- stupid me, I made the patch against 6.x-1.1 instead of dev
- got me, I'm working on Windows right now (no Linux around to make things right)
- the missing
$lid
was changed, in the working copy I have running it relies on another module of my own (apix_db
), but being this a patch I removed that dependency I wrote the$query
. (I swear I tested it!) but my patched version also have broken$lid
s and this is vitalI'll come back to you soon
Comment #3
matkeane CreditAttribution: matkeane commentedHi,
If it's easier for you to roll patches against 6.x-1.1 in the short term, that actually makes them easier for me to test, and I can set up a test site with the dev release once any creases are ironed out.
Comment #4
arhak CreditAttribution: arhak commented@#1 & #3 I apoligize about the first rushed patch, it wasn't working against dev because I left a couple of unrelated changes (which address another minor improvements) now cleaned out
new attached patch applies against both 1.1 and 1.x-dev
a working screenshot is also attached
PS: CR line feeds moaning remains
Comment #5
matkeane CreditAttribution: matkeane commentedHi,
OK, I've just tested the latest patch against 1.1 and it works fine now. I have two types of taxonomy - some use translated terms and one (for historical reasons) uses linked terms. With the patch, the translations show up when I edit a translatable term - and the links to the translation edit page work now! If I edit one of the terms with linked translated terms, nothing shows up, so I think it all works as it should. This was on a site with around 500 terms and 8 languages (with varying degrees of completeness of the translations).
For me this works as advertised, although I haven't yet tested it against the latest dev release. In any case it's a UI change, so there shouldn't be any side-effects. If somebody else could test this, I think this could be marked as RTBC and be considered for inclusion in the next release.
Comment #6
arhak CreditAttribution: arhak commenteddo you think that same UI improvement would be desirable for "Per language terms" vocabularies?
"Per language terms" vocabularies gets the "Translation" tab (local task) which I think is the perfect fit for that use case
don't you think?
Comment #7
matkeane CreditAttribution: matkeane commentedYes, I agree, I only mentioned it in case somebody does the same (dumb) thing as me - picks a term at random, clicks on edit, and can't see any difference after applying the patch! Then I remembered about the two different methods of translating terms, and found a more relevant example...
So the only reason I haven't marked this as RTBC is that 2 testers seems too few to be called a 'community'.
Comment #8
arhak CreditAttribution: arhak commentedsee also #582438: improve content types UI support
which have similar feature for content types (i18ncontent)
Comment #9
matkeane CreditAttribution: matkeane commentedOK, so I've been running with this patch in place for over a week, and I can't see any side-effects. Then I came across this blog post - http://www.unleashedmind.com/en/blog/sun/any-drupal-developers-out-there - where it's said that: "Developers [...] cannot mark their own patches as "reviewed & tested by the community" [...] someone else has to ..." - so I'm marking this as RTBC.
The only down-side I can see is that, in order for users to be able to use this feature, they would need the 'administer taxonomy' permissions, which is not something that I like to hand out to everybody. However this patch would still be useful for trusted users, or perhaps in tandem with the 'Taxonomy Delegate' module - http://drupal.org/project/taxonomy_delegate - so that users could modify only certain vocabularies.
Comment #10
matkeane CreditAttribution: matkeane commentedOops, forgot to actually change the status when adding my last comment!
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commented#9 "The only down-side I can see is that, in order for users to be able to use this feature, they would need the 'administer taxonomy' permissions"
This looks nice. However this just supports a user story, on which the tanslator is the admin too. For easier on page translation I'd recommend this other module, http://drupal.org/project/translation_table
For i18n modules we try to keep them as simple as possible and not making any assumption about how the translation workflow will look like, so we are not adding translation links everywhere.
Maybe you can post the patch for that other module or work on improvements for it.
Comment #12
arhak CreditAttribution: arhak commented@#10
why are we talking about the workflow of the translation?
why phrases like "tanslator is the admin too" & "the only down-side"
please, forgive me to be straightforward:
currently the only down-side I can see, is a useless link to the translation interface search on every term page, which is a huge usability issue, since all of them lead to the same useless place
1- If an admin/translator/whoever (since I haven't touched/questioned roles/workflow) gets to the term page, it would be actually nice to have links to its translations as well for a matter of accessibility (not as an UI for translator, which would be the job of translation_table module for instance).
This statement is backed up by the fact that i18n module has included a link to the translation search.
2- If such a link is already there, why not improve its usability?
3- The complexity of the module doesn't grow that much. It is just a matter of filling up an existent case of a
switch-case
blockI think this should be re-considered
Comment #13
matkeane CreditAttribution: matkeane commented@ #10
I'm disappointed to see this marked as 'won't fix', so here are my closing arguments, in the hope that you might reconsider:
I use the 'Translation table' module and it's great. However, with a vocabulary with 200+ terms in 8 languages, the admin page becomes a bit unwieldy - at least the parts of it that I can actually see on my monitor without scrolling across (to where I can no longer see the original term). If I add a new term in the vocab, I might have to navigate to the 3rd page of results, and then scroll down, to find it. This patch offers a similar translation overview for an individual term in a way that I find much easier to read and can immediately see when editing a term. I think that's an improvement.
As to the workflow/permissions issue - The "the only down-side" quote is from me in #9. I mentioned this in order to be clear about what the patch does. On its own, this patch provides a usability improvement which, in many use-cases, only admin users will see. However, combined with another module which allows more granular permissions, the patch becomes useful to other user roles as well. This is a pretty common situation with Drupal anyway, so I don't see this as a reason to refuse the patch, it was just clarification about its use.
Comment #14
arhak CreditAttribution: arhak commented@#13 ++1
yes, it would be the same as the Drupal way is all around
Comment #15
arhak CreditAttribution: arhak commentedshould I create a new project for this?
kind of i18n_bonus?
can you suggest proper name for such a module?
Comment #16
arhak CreditAttribution: arhak commentedI opened a forum topic Gathering more i18n support
Comment #17
Jose Reyero CreditAttribution: Jose Reyero commentedOk, reconsidering the "wont fix"...
I've created this new module here to gather all these UI enhancements: http://drupal.org/project/i18nui
So new modules welcomed there, feel free to use i18nui* namespace for them. I think a 'i18nuitaxonomy' would be a good start.
Then I'm thinking the 'i18nui' module itself will enable all modules in the pack and set up the basics for a mulingual site.
Sounds good?
(I'll grant the cvs commit access to people who wants to maintain their modules there)
Comment #18
arhak CreditAttribution: arhak commentedok, I can provide the starting code for taxonomy
patches or co-maitenance?
patches against what HEAD? (I would need the dev tarball, since I can directly use CVS due to firewall)
did you review usability?
PS: these namespaces are getting awful i18n-UI-taxonomy is poorly read from i18nuitaxonomy
Comment #19
arhak CreditAttribution: arhak commenteddid you read "The Peter Principle"?
this is a beautiful Lateral Arabesque
Comment #20
Jose Reyero CreditAttribution: Jose Reyero commentedNot really. Please read http://groups.drupal.org/node/37360
About the namespace, agree it is ugly, but also it is simple/short enough and will avoid name clashes with hooks of other modules.
Anyway, the module name is just a name for coding and it doesn't need to show up anywhere. But I'm a lazy coder and want it short :-)
But we can also build everything into the i18nui.module, as long as we add some basic checks before rewriting the forms/pages (module_exists, isset $form['language'], etc, etc...)
Comment #21
arhak CreditAttribution: arhak commentedI don't feel
i18nUI
states what this issue is aiminghttp://groups.drupal.org/node/37360#comment-108586
I think point 4 deserves examples.
The simplest example would be a "free tagging" vocabulary. Translators use their UI to make almost all translations, but find some (technical?) terms difficult to translate:
- Initials: RSS, XSS, CVS, etc
- Internet/Informatics slang:
--- feed = alimento, alimentar?
--- tip = propina?
--- log = bitácora?
--- blog = bitácora?
--- logged = autenticado?
--- forum = literally foro or twisted debate, discussion?
--- and all those terms that requires debate/suggestions for any particular language
The final call for the above can be made by the Administrator while browsing the site's vocabularies in the administrative back-end he/she is used to, instead of the translators tool he/she isn't familiar with.
The above example might sound alike Drupal's translation issues, but they are in another scope. The translators teams probably found their way and agreed to translate blog as bitácora, but a site having no blog at all might find that word entered through free tagging vocab and will face the same dilemma for the first time.
A more realistic/technical example: press' photographers categorizing their photos with IPTC.
- An English spoken photographer enters the IPTC category WAR (it is a standard)
- The Spanish translator will attempt GUE (knowing that IPTC categories are 3 letters only).
- An administrator OTOH (being more close to the problem) catches this error and wants to take over. Or probably knew it from start and told the Spanish translators not to translate that IPTC vocabulary. What does he/she have to do to translate WAR to DCG? (category Unrest. Conflicts & War translates to Disturbios y Conflictos according to EFE).
Conclusion:
- Taxonomy's administrative pages are there for who ever reaches them.
- Whoever get to a admin term page should be able to overview everything about that term (that's why he/she is seeing the description as well, even when nobody sees it in the site)
- Performance impact? For what? A single page which translates a single term into 12 languages?
- I think everyone would pay that price
Comment #22
Jose Reyero CreditAttribution: Jose Reyero commented@arhak> "I don't feel i18nUI states what this issue is aiming"
Do you mean about the whole 'i18n ui' package idea, or about 'i18nui' module?
If you think something like 'i18nuiadmin', 'i18nui_admin' module would work better please go ahead... It was just an idea. However we need some balance between 'having a i18nui module for any i18n module' and mixing different things in one module.
About whether admins need to be able to translate on page or not I wouldn't discuss that... Well, sometimes yes, sometimes not, depends on your site. But if you have several translatable items (name, description, help...) and 20 languages that can be really too much for a single page.
So, the only thing about module naming is that they need to package homogeneous features and don't overlap. So
i18nui_admin, 'Add on page translation options for administrators'
that makes sense, we'll put all that kind of options in that module... Also maybe the i18nui module can be some basic api for all these modules.
However other options are possible, so please let me know how it would make sense for you. We'll see how we can add all the features here in a sensible way before creating too many folders (that you cannot rename with cvs)...
Comment #23
arhak CreditAttribution: arhak commented1- "on page translation" -> I'm NOT talking about on page translation, that is what other modules do
we are talking here about "overview", a global panoramic about a particular term
this patch provides the "status" of the translations and "links" to the translation page
these links are just "more accurate" than the existing generic link to the translation search
2- we'll get this (an other issues) in somehow, that's for sure
3- I'm not complaining about names (besides namespaces are becoming long)
I was talking about the project description
I really don't know what current sites does with taxonomy's administrative page, but whatever they do, lets make it easier, lets improve cross-linking related features, lets target destinations where they may find useful to go.
EDIT:
typo fixesComment #24
arhak CreditAttribution: arhak commentedhere (in this particular issue) we aren't talking about permission's set up, nor translating anything
just linking to existing translations once we are seeing the "overview of a term"
who can access does pages?
don't care,
whoever Drupal made them available
we are not changing any logic in here
why to provide such links into a taxonomy's term page
because
i18n
does it already, many users found it useful and want to improve it a littleComment #25
arhak CreditAttribution: arhak commentedI really don't know how could I make my self clearer
There are other issues/improvements (like #582438: improve content types UI support)
that really introduces "noise"
"noise" <=> new features / overwhelming admin pages
IMHO, this isn't the case
If
i18nui
is intended to pick up every UI improvement"recommended for sites where a small number of administrators/editors take care of creating the content along with the translations"
then it will end up being an unpopular module
It should instead aim what the community might find as a "must have" accessibility/usability features
- for translator, whenever there is currently access using translation permissions
- for admins, those who currently have access to every administrative page
Comment #26
Bilmar CreditAttribution: Bilmar commentedSubscribing - I am still getting the below warning with #338630: Locale is unable to rebuild lost Javascript translation files committed. Can anyone please help?
Comment #27
arhak CreditAttribution: arhak commented@#26 please, keep this issue on topic
refer to #338630-147: Locale is unable to rebuild lost Javascript translation files
or open a new issue
Comment #28
Bilmar CreditAttribution: Bilmar commentedsorry I saw a post where this was referenced and thought it may be related
I will follow at #338630: Locale is unable to rebuild lost Javascript translation files. Thank you!