We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 4805 - Translator Plugin enhancements (could be ported wherever needed!)
Translator Plugin enhancements (could be ported wherever needed!)
Status: NEW
Product: OJS
Classification: Unclassified
Component: User Interface
PC Windows XP
: P5 enhancement
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2009-10-09 05:21 PDT by Ramon Fonseca
Modified: 2012-09-21 15:53 PDT (History)
2 users (show)

See Also:
Version Reported In:
Also Affects: OCS 2.3.4, OMP 1.0


Note You need to log in before you can comment on or make changes to this bug.
Description Ramon Fonseca 2009-10-09 05:21:19 PDT
Hello all,

Just a few enhancements on the interface, if possible:

1 - Enable mouseover effects on long tables. This is enabled in some places, as static effects on the submission queue. In the translator plugin list of files, it's easy to click on the wrong "edit" link as all the table rows are pretty much the same. A hover effect would ensure that we are on the right row, especially with wide screens. Bugzilla has this effect when viewing the bug list (after searching..). Hopefully, this was clear enough.

2 - The plugin should remember the previous page we were in before editing a file. That is, when we save a file, we are sent back to the first page of the list. When editing emails, for example, the most productive way is to open all similar messages (i.e, REVIEW_*) in new windows, which advanced users tend to do, although the Translator plugin is an administration tool.

3 - The plugin should have a visual confirmation that the file was edited. Either a different background color or a check mark at the end, so that we are aware that that file as edited. It may be difficult to track repeated editions to the file. Maybe keep the editing history for the duration of the session.

3 - Enable navigation on hosted journal list. In the translation installation there are quite a few, and with the user tools enabled, the page is quite long. An alpha list, as well as numbered pages should improve navigation. Again, this could/should be ported to the table of contents as well. 

In the table of contents, maybe enable a paging by section, enabling the editor/author to define the order of articles - use alphabetic, random, by page number, by author, or rating (either user comments or something similar), or any other we may think of, as well as an alpha list for sections (or a dropdown menu, not sure...). Could this be implemented as a plugin?
Comment 1 Ramon Fonseca 2009-10-09 05:26:07 PDT
Hello all,

Carlos just thought of another general enhancement:
- Display paging at the top and bottom of the list, especially for long pages. Probably display the top one when the list is greater than 10 or 15 items long. For example, we have set it to display 30 and we need to get to 31, we have to scroll to the end of the page (CTRL-END or Pagedown) to access the navigation.
Comment 2 Ramon Fonseca 2009-10-09 06:12:11 PDT
Hello all,

On another note, the tranlator plugin did not check REVIEW_REMINDER_* messages for variable consistency.
Our translations had a typo in the variable {$reviewDuedate}, which was just fixed in the translation installation available, because we were testing crontab and scheduled tasks.
Comment 3 Alec Smecher 2009-10-09 10:22:23 PDT
Thanks for the feedback, Ramon; ideally, we're looking for some external tool to help us maintain translations, but nothing has surfaced so far. I'll keep this feedback open against the PKP WAL for consideration if we can't find something.
Comment 4 Ramon Fonseca 2009-11-24 09:34:49 PST
Hello all,

Another improvement is for the plugin to display a context of where the key is used. Something of a description of what and where the text is used. There are things that are hard to translate if we can't see where it's applied.

Zoho has a Javascript that allows users to submit translation suggestions through the interface itself, while using the system.

Maybe JQuery could help with this feature, through its XML HTTP Request, although it would be necessary some kind of translation integrity check, like the Translator Plugin already has.
Comment 5 Ramon Fonseca 2010-08-13 10:27:46 PDT
Hello all,
One more enhancement for the translation overall.
Is it possible to use variables within the translation text?
I assume it may be possible, but how can we add, for example, a locale key within the text? There are quite a few situations where a command or button, which has a locale key, is referenced in another locale key.
Couldn't this be automated?
This would simplify the translation process, as we wouldn't have to remember what we typed in the other key.
Comment 6 Ramon Fonseca 2010-08-13 12:02:50 PDT
Hello all,
One other comment on the translation and localization files.

It would be really nice to have locale key variables within other locale keys when appropriate. This would prevent typos and forgetfullness, as we have locale keys referencing buttons and icons all the time. If the locale key for the icon or button is used, instead of just text, it would make life easier, as the text would only be kept in one place, such as roles, titles of editing and submission processes, and so on...
Comment 7 James MacGregor 2010-09-03 16:24:46 PDT
More from Ramon: 

-- Add the date of modification of the file on the table listing, along with the requested background color change of recent edited files. This way, we can see how fresh the translation is. Adding interactive headers is not essential, but would be an awesome plus!!

-- Add a check icon for files in editing. This way, collaborators would know who is working on what files. Joomla's JoomFish is quite interesting, although it's exclusive to Joomla.