Some quick impressions:
- It took a while for me to understand that the big text is the message definition, I thought it was an error message (the warnings about missing parameters and so on: where will they be, by the way?).
- There's no connection between the message definition and its documentation (the definition is isolated in the middle and connected to the text area by vicinity; the whole right side "goes to" the translation).
- How will "used x times" link to the messages where it's used and is this clear to users or just a way to hide the feature so that it's shown and used only to/by people knowing and wanting it?
- No edit summary allowed? Are they supposed to be replaced by the "integrated comments"?
- The translations in another languages are more or less as long as the definition and the translation: aren't they going to take a lot of vertical space (hence of scrolling) with long messages?
- Cropping long documentation seems very unfriendly, will require lots of clicks to "read more" even for basic translations of messages with many parameters and so on.
- I'm not sure of how the "clicking flow" will be with all the buttons on the right, too hard for me to have thoughts about it.
--Nemo 08:19, 3 September 2012 (UTC)
More quick impressions:
- It took a long time for me to understand that the big text is not an error message but a message definition.
- Do not truncate message definitions and documentations in screens where you can type/alter translations. You could make truncation depend on a user toggle which can be permanently set to DON't.
- I have some 30 support languages shown all the time, though usually, for the majority of languages, there are no translations (yet) - I wonder how that will affect screen layout for me.
- This is not a genuine matter of the translation interface alone, but we SHOULD have some visual indication of message use: block of text, inline text, action button label, action link, e-mail message, page title, table column header, technical item, ... just come to my mind. Of course, there are more. At least the most common message types should be instananously recognizeable to tranlators.
Generally, I apreciate the ideas about a label system, if labels are small, or experienced users can select "reduced icon sizes". Since labels are hihgly repetitive, they tend to loose importance over time, while they may be a good guidance for the newbies.
Please consider allowing users to add their own label types, such as in the result set of my latest search or in the saved search named X or just manually flagged such-and-so. Rationales:
- Quite often one can only translate with some probability or uncertainty. Rechecking later, when more message documentation has become available, and you got a better feeling for the peculiarities of a product or extension new to you, would be a good idea, and requires some way to point to the messages in question.
- Sometimes for similar reasons, you want to mark all or some messages using a specific translation, word or phrase for possible later review.
- Keeping wording and style consistent is a time consuming task which is made easier when you can label messages for longer that a session, or for collaborators.
- Obviously, Added or updated message documentation should be a marker and selector available to all translators. Make minor edits desectable, we do not want to hunt typing error corrections. Allow easy access to a diff browser for the documentation changes, and allow editors to mark translations as conformant with updated documentations without having to re-save them.