Bug 15308 - Suggested new interface for item type translation process
Summary: Suggested new interface for item type translation process
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: I18N/L10N (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-04 15:37 UTC by Owen Leonard
Modified: 2019-10-08 18:01 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Mockup of suggested changes (27.04 KB, image/png)
2015-12-04 15:37 UTC, Owen Leonard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2015-12-04 15:37:07 UTC
Created attachment 45418 [details]
Mockup of suggested changes

I find the new item type translation interface confusing, so I have attached a screenshot showing an idea for how to change it.

We've got two competing modes in the current interface: A typical form for adding new translations and a hidden inline editing system for existing translations. I think we can combine the two:

- List all installed languages.
- Put an "Add" in rows for languages which lack a translation.
- Put an "Edit" link in rows for languages which have a translation.
- Use "Delete" text of the delete link for clarity and consistency.

The way I picture it, clicking the "Edit" link would move the focus to and highlight the existing text in such a way to suggest that it is editable (perhaps by imitating the style of a text input).

Clicking the "Add" link would move the focus to the "Empty" cell and set the style of the cell in a way to suggest that it is editable.

I would further suggest that while an add or edit is being performed, the corresponding add/edit link be replaced with a save button. Right now the user has to both guess that the text is editable and guess that the changes will be saved.

This is a good opportunity to establish a good usable pattern for using contenteditable interactions so that they can be extended to more places in Koha.

I would love to hear comments.
Comment 1 Jonathan Druart 2016-01-06 11:28:50 UTC
Owen,
That makes sense to me!
Note that at the beginning bug 14100 did not provide edition. It was more a POC than a very shiny  proposal :)

A few notes:
- You have 'Add' and 'Delete' on the same line, it does not make sense
- The already translated strings could be on top of others
- The idea was other "entities" to translate, as system preferences, see the 'Think further / Todo' on one of the commit description.
Comment 2 Jonathan Druart 2016-01-06 11:29:26 UTC
Here it is:
> Think further / Todo:
> 1/ Update all occurrences of the item type's description (DONE)
> 2/ Implement for authorised values
> 3/ Implement for syspref value (at least textarea)
> 4/ Implement for branch names
> 5/ Centralize all the translation on a single page in the admin area
> ...
> N/ Implement a webservice to centralize all the translations and give
> the ability to sync the item types/authorised values description with
> the rest of the world (push and pull).

The 5) should be kept in mind.
Comment 3 Katrin Fischer 2017-07-09 16:24:45 UTC
Hi Jonathan,

I was looking at this again, but not sure I understand the comment about the Add/delete being in the same line. Can you explain a bit more? Can we get this unstuck maybe?
Comment 4 Jonathan Druart 2017-07-10 18:55:26 UTC
(In reply to Katrin Fischer from comment #3)
> Hi Jonathan,
> 
> I was looking at this again, but not sure I understand the comment about the
> Add/delete being in the same line. Can you explain a bit more? Can we get
> this unstuck maybe?

It was not important. If there is no translation we should only see "Add", "Delete" will not do anything.
Comment 5 Katrin Fischer 2017-07-10 20:29:07 UTC
Ah yes, that makes sense. Owen, are you still interested in doing this?