[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Workflow for suggesting translation corrections
From:       Agron Selimaj <as9902613 () gmail ! com>
Date:       2011-06-19 16:21:52
Message-ID: BANLkTi=5nciPJ2Jivs+-nqZWhwCqgXiCjg () mail ! gmail ! com
[Download RAW message or body]

This is, in a way, similar to the missing help resource in KDE context help.

In dialogs where you see the "?" on the title bar, when there is no
help for a certain text box, or a button on the dialog, your email
client comes up with a bunch of resource identifiers in the body of
the message.In this message we type what we think would be helpful for
other KDE users and that will probably get published with next
release.

In the above described process, you could replace the email client
with Lokalize, and make your suggested workflow of handling .po files.

I guess you could initiate resource editing/translation mode by
clicking on the "?" with another modifier key.

But, this context help has limitations. I am not sure how it works
with main application menus or other widgets where you have to click
to expand them to see more resources in them.


//Agron


On 6/19/11, Mike Dupont <jamesmikedupont@googlemail.com> wrote:
> I have thought about such an idea before, It would be great to allow for a
> user to be able to click on a text in the screen, or turn on a special mode
> to be able to select and help change the bad translations in a program at
> runtime.
>
> It could also be done by making an extension to the gettext that would
> provide a log file view of the translations fetched by gettext and allow a
> user to review and update them,
> mike
>
> On Mon, May 23, 2011 at 1:47 AM, Dashamir Hoxha <dashohoxha@gmail.com>wrote:
>
>> Dear friends,
>>
>> After writing the email that is forwarded (about how to make
>> it easy for beginners) and after looking a bit closer to Lokalize,
>> I realized that it is possible to implement the proposed workflow
>> using the existing features of Lokalize, mainly due to its ability
>> to be extended by external scripts. However I am not familiar with
>> python or ruby, so I am going to describe how I think it can be
>> done, hoping that somebody will be able to help.
>>
>> First of all I will describe again the workflow (scenario) that
>> needs be implemented, then I will also describe how I would do it
>> (if I new python/ruby etc.)
>>
>> Functional Description:
>> -----------------------
>>
>> Suppose that somebody spots a wrong translation that would like
>> to correct or improve. He clicks on it with the middle button of
>> the mouse (or Shift + Left Click, or some other combination).
>> This will fire up Lokalize (if it is not already open), will open
>> Translate Memory, will search for the text of the widget that was
>> clicked, and will open the corresponding string in edit mode.
>>
>> The user corrects the translation and saves it. Then he clicks the
>> button or menu item 'Apply' (which formats the edited PO file and
>> saves it to the right place) and restarts the application with the
>> wrong translation in order to check how the new translation looks.
>> He may decide to keep the modified translation, or to revert back
>> to the previous one, by clicking the menu item 'Revert'.
>>
>> The user can make several corrections/improvements like this, in
>> several applications. Then he decides to share these improvements
>> with the others. At this point he can select the menu 'Submit',
>> which will find out all the modifications made (since the last
>> time that the suggestions were sent) and send them in a proper
>> format to the translation team. They may be sent by email (in the
>> ediff format) or by submitting them to some kind of web service.
>>
>> The translation team reviews the suggestions and decides to apply
>> or discard them.
>>
>>
>> Technical Details:
>> ------------------
>>
>> For this to work, the Translation Memory should be populated
>> automatically with all the existing translations. For Ubuntu
>> these can be found on:
>> /usr/share/locale-langpack/lng/LC_MESSAGES/*.mo
>> First they are converted to .po by 'msgunfmt' and then stored
>> to a directory used by Lokalize. This can be done automatically
>> when Lokalize is installed, but can also be done from a menu
>> item (named for example 'Init TM').
>>
>> Then, in order to keep track of modifications, these files can
>> also be kept under version control (SVN or GIT). Another solution
>> would be to keep always a backup copy whenever a PO file is modified,
>> in order to be able to revert back or to make the ediff.
>>
>> When the menu item 'Apply' is clicked, then the PO file that is
>> being edited is converted to MO and is saved to a proper place,
>> where it can be picked up by the application (once it is restarted).
>>
>> When the menu item 'Revert' is clicked, then the modified PO file
>> is replaced by the backup. The MO is generated and stored again.
>>
>> When the menu item 'Submit' (or 'Share') is clicked, then the ediff
>> is calculated between the PO file and the backup (for each
>> PO file that has a backup), and an email message is prepared,
>> ready to be sent to the main contact point of the translation team,
>> or to each of the translators of the modified files, or to the
>> mailing list of the translation team.
>>
>> The ediff-s can be calculated using the 'pology/poediff.py'.
>>
>> http://techbase.kde.org/Localization/Tools/Pology/PO_Embedded_Diffing#Producing_Ediffs:_poediff
>> The ediff format will make it easy for the translation team
>> to review and apply these patches.
>>
>>
>> Cunclusion:
>> -----------
>>
>> I think that all this functionality can be implemented easily
>> using the ability of Lokalize to be extended by external scripts:
>> http://docs.kde.org/development/en/kdesdk/lokalize/scripting.html
>> However it may also be a good idea if these features are built-in
>> on Lokalize.
>>
>> About 'Widget text capture' I don't know why it does not work for
>> me (does not do the automatic search on Translation Memory). Also
>> I don't know whether it is possible to use it for GNOME applications
>> (or other applications types) as well. It would be good if it were
>> a universal feature.
>>
>> Best regards,
>> Dashamir
>>
>>
>> -------- Original Message --------
>> Subject: Beginners translation guide
>> Date: Wed, 04 May 2011 13:38:43 +0200
>> From: Dashamir Hoxha <dashohoxha@gmail.com>
>> To: KDE i18n-doc <kde-i18n-doc@kde.org>
>> CC: Agron Selimaj <as9902613@gmail.com>,  Laurent Dhima
>> <laurenti@alblinux.net>, Albert Astals Cid <aacid@kde.org>
>>
>> Hi,
>>
>> I am still struggling to understand what a complete
>> beginner should do, in order to contribute suggestions
>> and alternative translations (which can be reviewed and
>> accepted/rejected by the translation team).
>>
>> Is there any "complete beginner guide" for l10n (as
>> far as you know)?
>>
>> Besides the hard and respectable work of the translation
>> teams, I think that it is important to get feedback and
>> suggestions from the everyday users as well, because after
>> all, they know the program that they use everyday better
>> than us. But this cannot happen unless there is an easy
>> workflow for submitting suggestions.
>>
>> I am a programmer and I had to use in the past i18n and l10n
>> for my programs. So, when I had to fix the translation of
>> KTurtle, I knew that there must be some MO file, I located
>> it, converted it to PO with msgunfmt, edited PO with vim,
>> converted back to MO and tested how it looks like. The
>> only challenge for me was how to submit my changes upstream
>> for review and approval.
>>
>> However I don't think that we should ask ordinary users
>> to learn gettext details, in order to be able to submit
>> suggestions. A guide for complete beginners should not
>> mention gettext at all, and neither git/svn or other
>> technical stuff.
>>
>> Such a guide should explain just:
>> - what tools to use and how to get them (Lokalize should
>>  be one of them)
>> - how to correct the existing translations
>> - how to test locally these corrections
>> - how to share them with others (by sending them to the
>>  translation team for review and approval)
>>
>> There may be several variants of such a guide, depending
>> on different work environment of the users. For example,
>> some of the cases may be these:
>> - the user is using KDE
>> - the user is using GNOME
>> - the user is using KDE-for-Windows
>> - the user is using GNOME/KDE programs on windows
>>
>> The steps of the guide should be easy, and if possible,
>> should be supported by the tools. For example, I have
>> discovered that Localize has a nice tool that is called
>> 'Widget text capture'. It didn't work for me (I don't
>> know why) but the idea is that once this feature is enabled,
>> you can click with the middle button on any non-editable
>> text, anywhere, on any program, and the corresponding
>> translation strings will be opened automatically on Localize.
>>
>> Correcting and saving them this way will be very easy.
>> Then, they can also be applied with just a button, having
>> also the possibility of reverting back to the original translations.
>> This will be useful for testing how the changes look like.
>>
>> Submitting all the recent changes can also be automated easily,
>> with the click of just one button. However, the user may have
>> to follow a registration procedure for the first time, giving
>> his name and email, and probably verifying his email as well.
>>
>> On the other hand, there should be some automated tools for
>> the translation teams as well, so that they can handle easily
>> all the suggestions. Probably such tools can be built on top of
>> Pootle or some other existing system. They should support
>> the identification of the suggestion submitters, statistics
>> about them, manage the review of the suggestions (for example
>> assigning each suggestion randomly to two team members for review),
>> and the approval of the suggestions (if they get positive evaluation
>> from the reviews).
>>
>> Probably there are any projects that try to facilitate the
>> workflow for the l10n/translation. If you are aware of such
>> projects, please let me know about them as well, so that I
>> can try to share and discuss my ideas with them.
>>
>> Best regards,
>> Dashamir
>>
>> --
>> Dashamir Hoxha
>> GPG: 4F97 4EDE C739 4C3D 361E 16D3 FD06 AA8E 55D5 9B28
>> In God we trust. Everybody else we verify using GnuPG!
>>
>>
>>
>>
>
>
> --
> James Michael DuPont
> Member of Free Libre Open Source Software Kosova and Albania flossk.org
> flossal.org
>
[prev in list] [next in list] [prev in thread] [next in thread]