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

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:



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.

Issue #2

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

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

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.

.
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

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

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:



Should really say something like this:



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

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 doesn't work properly.

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 must 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



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:



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:



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



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



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

Issue #???

What about starting to translate, and then finding you need to do an original contribution while translating? I.e. mixing translation and original authoring at the same time?