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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

matkeane’s picture

Hi,

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.

arhak’s picture

Version: 6.x-1.1 » 6.x-1.x-dev
Status: Needs review » Needs work

@#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 $lids and this is vital

I'll come back to you soon

matkeane’s picture

Hi,

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.

arhak’s picture

Status: Needs work » Needs review
FileSize
30.9 KB
5.09 KB

@#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

matkeane’s picture

Hi,

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.

arhak’s picture

do 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?

matkeane’s picture

Yes, 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'.

arhak’s picture

see also #582438: improve content types UI support
which have similar feature for content types (i18ncontent)

matkeane’s picture

OK, 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.

matkeane’s picture

Status: Needs review » Reviewed & tested by the community

Oops, forgot to actually change the status when adding my last comment!

Jose Reyero’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

#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.

arhak’s picture

@#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 block

I think this should be re-considered

matkeane’s picture

@ #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.

arhak’s picture

@#13 ++1

yes, it would be the same as the Drupal way is all around

arhak’s picture

should I create a new project for this?

kind of i18n_bonus?

can you suggest proper name for such a module?

arhak’s picture

I opened a forum topic Gathering more i18n support

Jose Reyero’s picture

Project: Internationalization » Internationalization UI
Version: 6.x-1.x-dev »
Status: Closed (won't fix) » Needs work

Ok, 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)

arhak’s picture

ok, 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

arhak’s picture

did you read "The Peter Principle"?
this is a beautiful Lateral Arabesque

Jose Reyero’s picture

Not 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...)

arhak’s picture

Version: » 6.x-1.x-dev

I don't feel i18nUI states what this issue is aiming

http://groups.drupal.org/node/37360#comment-108586

1- When a website has a typo or misspelling (in any language) the "webmaster" is the usual person to contact about it.
2- Translators may or may not have skills enough to audit themselves.
3- A website might not be equipped with the very best suit of modules to make translators live easier.
4- Technical translations may not be accomplished by translators.
5- Also, (...) small websites have a single admin which would be also the translator

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

Jose Reyero’s picture

@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)...

arhak’s picture

1- "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

recommended for sites where a small number of administrators/editors take care of creating the content along with the translations

It is not recommended for huge multilingual sites where there's a dedicated translation team that don't have admin/edit permissions for everything.

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 fixes

arhak’s picture

Relaxed permissions and not many options so it is easy to set up and get started with translations

here (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 little

arhak’s picture

I 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

Bilmar’s picture

Subscribing - I am still getting the below warning with #338630: Locale is unable to rebuild lost Javascript translation files committed. Can anyone please help?

warning: file_get_contents(sites/all/themes/example/js/jquery132min.js) [function.file-get-contents]: failed to open stream: Permission denied in /srv/www/example.com/public_html/includes/locale.inc on line 1708.
arhak’s picture

@#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

Bilmar’s picture

sorry 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!