[Scilab-loc] Update of launchpad to simplify the localization

[Sylvestre Ledru]

Le vendredi 26 juin 2009 à 02:17 +0400, Kirill Kirillov a écrit :
> Hi!
> 
> В Чтв, 25/06/2009 в 22:39 +0200, Sylvestre Ledru пишет:
> > Le jeudi 25 juin 2009 à 21:52 +0400, Kirill Kirillov a écrit :
> > > Btw, is it possible to enable support for the following statuses:
> > > - Translation unchanged since last synchronized 
> > why do you want this ?
> > > - Changed in Launchpad 
> > > Especially it would be useful to have the first status, which would show
> > > items already included into the last stable scilab version.
> > I am not sure to understand what you mean here :/
> > sorry
> It's OK, I'll try to clarify.
> 
> For instance, we have the following page opened:
> https://translations.launchpad.net/scilab
> 
> It consists of table with "Status" column.
> Currently status can be either "Untranslated" or "Newly translated in
> Launchpad". But legend on the same page has two more statuses, which
> I've mentioned before: "Translation unchanged since last synchronized"
> and "Changed in Launchpad".
> 
> I'm sure, that it would be useful to have these two last statues enabled
> to show which items were already included into last Scilab release and
> which included items have been changed in Launchpad since last release.
> 
OK, I understand. Can you open a bug report on launchpad to ask for this feature ? I will support
your proposal. I believe they can implement this feature pretty easily!

> > > And one more suggestion, if the same items have different translation in
> > > two modules, then during localization building such items are marked as
> > > fuzzy and therefore they would be untranslated in final scilab.mo.
> > > I think it would be more flexible to build translations per module. This
> > > would help to solve mentioned issue. Also users would be able to make
> > > their own localizations for toolboxes.
> > I wish I could but we would have to update all the code providing the name of the localization file for each modules...
> > but I agree that this problem should require a solution...
> 
> Should I open a bug to track this issue?
Yep, please. However, don't expect a fix quickly... I don't know how we could solve it... 
Maybe a preprocessing (based on gettext or not) which would check for
conflicting translation... 

Anyway, thanks for your input, it is always appreciated!


Sylvestre