History: Alain's test and feedback, 2008-02-05

Source of version: 20

I tried to eat our own dogfood this AM. Below is an account of what I found.

But before I go, let me congratulate L-P on an excellent job. Although it may look below like I'm bitching and complaining, I'm not. I am astounded by the amount of work that L-P has done in such a short time. 

But there are many things that could be improved and I talk about them below.

What I tried to do was to create a translation of my page ((Alain Désilets)) on the site, into French and Spanish

!Issue #1: Problem when translating pages that do not have langage assigned to them.

The page ((Alain Désilets)) did not have a language assigned to it at the start.

I clicked on Translate button, and saw a pick list of languages. I selected French, thinking that this would specify the language of the translation.

Unfortunately, this was a case where the source page did not have a language associated with it, and this picklist was for specifying the language of the source page. So I ended up with a source page in French.

Now, as it turns out, there was a message above the language picklist that said:

^No language is assigned to this page. Please select a language before performing translation.^

But it was in a microscopic font. And since I was in a translation mode, as soon as I saw the language picklist, I assumed it was for specifying the target language. In order to counter that assumption (which I think many users will have), we need to display a __much more prominent WARNING: style___ message.

Another thing that could be done to minimize occurences of these kinds of cases, would be to do a better job at guessing the language of a newly created page.

For example, if I just created the present page using a dangling link on page ((Cross Lingual Wiki Engine Project)), which is in English. In a case like that, I think it's safe to assume that the page is in English.

^__Response:__ This issue should now be solved. The message was made bigger in the first place to make it more visible as a warning. Second, the pages now get a default language when being created. If created from a page link in a wiki page, it takes the language from the linking page. Otherwise, it takes the site language (based on user preferences).^

!Issue #2: Need more prominent out of dateness status? Maybe not.

OK, so I changed the language of the original page to English, then proceeded to translate it to French and Spanish.

Then I changed the French page and added original content to it.

Then I went back to the English page, and expected to see some sort of warning that the French page was more up to date.

At first, I didn't see anything related to translations.

Then L-P pointed out to me that there should be a Translation module in the upper left corner.

__This tells me that maybe the information about translations and out of dateness should be somehow more prominent, or maybe closer to the language picklist at the top right.__ But maybe this would be crowding the UI too much.

!Issue #3: Minor tweak to language preferences dialog

Looking at the Page translation box, I noticed that it said that there was no page with more up to date content.

I asked L-P why, and he said it's because I didn't tell Mozilla nor Tiki site that I can read other languages.

So I went to my User Preferences page, in the Languages section.

I picked French as a language I can read. This added 'fr' to the list of languages. Then I clicked on Change Preferences button, and the picklist of languages turned blank. 

This was confusing to me. I thought there was a bug and it failed to register my prefernece. Eventually, I understood that the text field on the left is where the preferences are stored, and the picklist on the right is just a way to choose a language to add.

__Need to make that clearer.__ For example, the first item of the picklist, instead of being blank, should say something like "Pick a language to add". The text box should have a caption that says "Languages you can read". There should be a button that say "Add" beside the picklist.

!Issue #4: Page Translation box should provide info relevant for BOTH readers AND translators.

Once I changed my user preference to tell Tiki that I can also read French, I did see a box called __Page translation__ which said:

   "No translations with less up-to-date content match your preferred languages. More..."

But it seems to me it should say that the French version is more up to date, because this is what matters most to a __reader__. 

L-P said it wasn't a bug. He wrote it that way.

Of course for a __translator__, it might also be important to know what languages are LESS up to date than the current version.

Here's what I propose.

^There are *untranslated changes* for this page in your *preferred languages*. There are translation in your *preferred languages* that *need updating* 

*Translations outside of your preferred languages*^.

Where *abc* means a hyperlink with abc as anchor text.

The *preferred langauges* link would take you to the page for configuring your preferred languages.

The *untranslated changes* link would show you pages that are more up to date than the current one.

The *need updating* would show you pages that need updating and that you could do something about.

Finally, the *Translations outside of your preferred languages* link would be a kind of catchall that would list all pages needing updates and all pages that have more recent changes, in all languages supported by the site. This might be useful in case the user has not set his language preferences.

!Issue #5: Bug in translation tracking infrastructure?

At some point I changed the French version, but for some reason, English did not show up as needing to be updated from French. I tried to reproduce this problem without success.

!Issue #6: Minor improvements to translation dialog

Eventually, I was able to update the English version from the French. It worked quite nicely actually! I found the French diff on top of the English text box worked quite well, and enabled me to quickly zero in on what needed to be done. 

But here are some improvements.

The caption at the top that says:

^Edit: Alain Désilets, es

Comparing version 1 with version 5^

Should really say something like this:

^Update "Alain Désiets, es" based on "Alain Désilets, fr"

Changes that need to be reproduced in Spanish are highlighted below.^

Also, the diff is not as good as it could be. For example, I changed a phrase "il a été président de la conférence" to "il a présidé la conférence" to . 

This got highlighted as follows: "il a pr*a é*sid*t*é *président de* la conférence", which is hard to read. It would have been better if it had come out as: "il a *présidé* la conférence". 

Note that I tried different diff styles available in Tiki, and most of them seem to have this sort of problem except for HTML Diff. Unfortunately, HTMLDIff shows a side-by-side diff and we probably just want an inline diff. Oh well, it will have to do for now.

!Comment #7: Should "consecutive" changes be merged into a single translation bit?

Next, I did two changes on the French, in two shots (i.e. two saves).

Then I went to update English based on French, and I was pleased to see that the diff showed me the two changes together.

I was thinking about this issue when reading L-P's translation tracking architecture. It sounds like with this new architecture, different saves would be considered to be different translation bits. So does this mean that the end user would have to translate them in two different transactions? Or would it be better to consolidate "consecutive" translation bits into one bigger translation bit? What does "consecutive" mean in this context?

On the one hand, consolidating consecutive translation bits is good in that it avoids situations where the user needs to do multiple updates. In particular, if the author writes a sentence, saves, then reformulates that sentence, the translator would not have to translate the original sentence and its re-formulation. He would just translate the final version. (Note: translators tend to work in a mode where they write a first draft, then revise it and refine after the fact, so this may be very common).

On the other hand, keeping consecutive translation bits separate has the advantage of reducing granularity of transactions. This is important because in L-P's new architecture, there is an assumption that when a user is updating a page based on another language, the update is considered completed as soon as the user hits the save button. But if the update is a large one, the user may want to click on save midway through translation. If translation bits are kept short, this is less likely to happen.

!Issue #8: Copying and pasting from the diff inserts weird end of line characters

A common practice with translators, is to start with the source text and write the translation over it.

When updating the English page based on the French, I found myself naturally copying highlighted content from the French diff, into the English edit text box, and then overwriting it.

But... when I do this, the following caracter: ↵ gets inserted at the end of each line.


!Issue #9: Translations should not have to always be done in one go

I think this is a biggie.

If I update the English version based on the French version, and hit the save button before I have completed the translation, the system considers that English and French are now up to date, and there is no more way for me to remember that it's in fact out of date, and what parts need to be updated.

This is a problem I have encountered when I developved multilingual features in LizzyWiki, and I was never able to find a satisfactory solution to it.

The solution I used was that the system kept nagging the user, asking him if the translation was complete or not. 

I suggest the following:

Under the save button, there would be a check box saying

^Translation completed^

This check box would be unchecked by default.

When the user saves a page, there would be some sort of page alignment checking algorithm that would try to guess whether or not the translation is completed.

If the user checked that box, but the system figures that something is fishy, i.e. the translation does NOT look like it's done, it would display a message saying something like this:

^The highlighted text below does not seem to have been translated. Are you sure you want to label this translation task as complete?^

Conversely, if the user did not check the box, but the system thinks that the translation is done, then it would display something like this:

^It looks like you have completed this translation task. Is that the case? Yes | No^

I think it shouldn't be too hard to implement this kind of sanity check on translation completion. In fact there are people in my group who have implemented something like that. And it's something that can lead to a cool paper. I'll investigate.

!Issue #10: Changes that have already been synchronized keep being highlighted.

Something is terribly wrong with the translation tracking.

I brought the system to a state where it showed En, Fr and Es as all being in synch with each other.

Then I added the following change to the En version

^----
This change will first be made in English, then translated to Spanish, then Translated to French. I will then look to see if the system considers that Spanish needs to be updated from French. 2008-02-05@15h34

----
^

Then I went to Fr version, and did Update from En.

This is what the system highlighted as changes that needed to be brought into Fr

^---
This modification was first made in French, 2008-02-05-@14h12


----

This modification was first made in French, 2008-02-05@14h56.

This sentence is part of the same change.

----

This modification was first made in French, 2008-02-05@14h57.

----

This change will first be made in English, then translated to Spanish, then Translated to French. I will then look to see if the system considers that Spanish needs to be updated from French. 2008-02-05@15h34

----
^

Looks like the translation UI is going back too far in the Fr versions.

L-P says he fixed that bug on his local version, but it's not live yet.

!Issue #11: Cannot mix translation and original editing in a same transaction

Say, I make a change to En. Then I update Fr based on En. Say it's a pretty long translation.

Since I'm a wiki-translator, I'm translating content that I care about and that I know a lot about. In fact, I am also a prolific author on that site.

While translating the change, I spot an error in a part of the text that has nothing to do with the translation I am currently doing. Chances are that I will go ahead and fix the error right therre while I'm still in the middle of a translation transaction.

Then I finish the translation, and I click on Save.

Problem is, the system now considers that En and Fr are in synch, eventhough my correction (which I did at the same time as translation) is not in the En version.

I think we need to figure out a way that people can swithc between translator and author modes within a same transaction. This type of scenario has happend to me often. Because I knew about the issue, I was able to be disciplined about it and just write down the change on a piece of paper, and delay doing it until I was done translating. But even there, I sometimes forgot that I wasn't supposed to do that. So for sure, "ordinary" users will have trouble splitting their personality into "translator" and "author" roles.

Again here, a solution could come from some sort of translattion verification feature. If the system sees a change that looks like it was not a translation of a change on the En side, it would signal that to the user, and maybe allow the user to label that change as being an original contribution as opposed to a translation.

History

Enable pagination rows per page

Information	Version
Tue 19 of Feb, 2008 21:52 GMT alain_desilets	30	Actions View Source
Tue 19 of Feb, 2008 20:39 GMT alain_desilets	28	Actions View Source
Tue 19 of Feb, 2008 20:29 GMT alain_desilets	27	Actions View Source
Tue 19 of Feb, 2008 20:25 GMT alain_desilets	26	Actions View Source
Tue 19 of Feb, 2008 20:16 GMT alain_desilets	25	Actions View Source
Tue 12 of Feb, 2008 21:18 GMT alain_desilets	24	Actions View Source
Tue 12 of Feb, 2008 21:13 GMT anonymous	23	Actions View Source
Tue 12 of Feb, 2008 20:45 GMT alain_desilets	22	Actions View Source
Tue 12 of Feb, 2008 15:12 GMT anonymous	21	Actions View Source
Tue 12 of Feb, 2008 15:06 GMT lphuberdeau	20	Actions View Source
Tue 05 of Feb, 2008 21:33 GMT alain_desilets	19	Actions View Source
Tue 05 of Feb, 2008 21:31 GMT alain_desilets	18	Actions View Source
Tue 05 of Feb, 2008 20:58 GMT alain_desilets	17	Actions View Source
Tue 05 of Feb, 2008 20:42 GMT alain_desilets	16	Actions View Source
Tue 05 of Feb, 2008 20:41 GMT alain_desilets	15	Actions View Source
Tue 05 of Feb, 2008 20:19 GMT alain_desilets	14	Actions View Source
Tue 05 of Feb, 2008 20:05 GMT alain_desilets	13	Actions View Source
Tue 05 of Feb, 2008 19:45 GMT alain_desilets	12	Actions View Source
Tue 05 of Feb, 2008 19:15 GMT alain_desilets	11	Actions View Source
Tue 05 of Feb, 2008 18:51 GMT alain_desilets	10	Actions View Source
Tue 05 of Feb, 2008 18:41 GMT alain_desilets	9	Actions View Source
Tue 05 of Feb, 2008 18:41 GMT alain_desilets	8	Actions View Source
Tue 05 of Feb, 2008 18:29 GMT anonymous	7	Actions View Source
Tue 05 of Feb, 2008 17:33 GMT alain_desilets	6	Actions View Source
Tue 05 of Feb, 2008 17:00 GMT alain_desilets	5	Actions View Source
Tue 05 of Feb, 2008 16:58 GMT alain_desilets	4	Actions View Source
Tue 05 of Feb, 2008 16:44 GMT anonymous	3	Actions View Source
Tue 05 of Feb, 2008 15:55 GMT alain_desilets	2	Actions View Source
Tue 05 of Feb, 2008 15:51 GMT alain_desilets	1	Actions View Source