lp-l10n-fr-community team mailing list archive

[Nicolas Delvaux <contact@xxxxxxxxxxxxxxxxxxx>]

Hi,


> > Launchpad can display these just fine.
> > For example:
> > https://translations.launchpad.net/pybik/trunk/+pots/pybik/fr/+translate
> > (notice the "Located in" string at the bottom of each field)
>
> Kind of. They still need to find the file and line number manually 
> since
> they are not URLs. For one string, this isn't a big deal, but where
> there are hundreds, it can be a real pain. Moreover, that's not actual
> machine readable metadata, but just a verbatim copy of a comment 
> string
> created by xgettext.

Indeed, but it's better than nothing :-)
And even if this is not machine readable, it can provide a bit of 
context by itself (for example if a string comes from a file named 
"credit.c" or settings.c"...)


> > So, what's the difference with the 2nd string, "Studio Software"?
>
> I actually only see one string for "Studio Software". Maybe you could
> show me what you mean?

I'm referring to [1] and [2].
I asked you about the meaning of "Studio Hardware" and you explained 
that this is basically a header for a software credit field.
Which seems confusing to me, because I imagine this definition would 
rather fit the "Studio Software" string, wouldn't it?

Or maybe we had a misunderstanding and you were referring to "Studio 
Software" which probably means that "Studio Hardware" refers to hardware 
credit (so people who lend you specific hardware?)



> > You could, for example, provide a PPA so that translators could then
> > install the latest snapshot with the latest translations from 
> > launchpad
> > (and it could be updated automatically daily, as some other projects
> > do).
> > This way translators could easily test their translations without
> > having to know how to build the project.
> > Don't forget that most translators are not developers.
>
> The problem here is that getting a suitable runtime environment for 
> the
> software is not as straightforward as what comes typically in a
> prepackaged deb. This software runs off of optical media and needs 
> about
> 14 GB of mission data to drive it in the way you'd need to do what you
> are asking for.

Maybe I'm about to ask stupid questions, but here they are anyway:

If VLR is used to restore these data (are they freely available?), it's 
only useful once isn't it?
So, in this case, is it really necessary to localize it?
(will anyone want to use it once the restoration is over?)


> > There are indeed such translators, but not many :-)
> > As you probably understood now, my point is that you should do 
> > whatever
> > you can to lower the technical knowledge needed to contribute good
> > translations to Avaneya.
>
> I understand where you are coming from and there is not much that we
> disagree on. The only thing you need to realize is that I'm quite 
> under
> staffed right now and have a long check list of dozens of things to
> solve before I can make the first public release. If it had been 
> within
> my means to make translations easier, I would have done that.
> Translations are very important, French in particular for my fellow
> French speaking citizens here in Canada or abroad.


As a developer who also manage some projects alone, I fully understand 
your situation :-)
But it's important to agree on what should be done. For example, next 
time you add a translatable string in Avaneya, don't forget to add a 
context comment at the same time ;-)

Do you have a deadline upon when the translation should be finished?


Cheers,
Nicolas

[1] 
https://translations.launchpad.net/avaneya/trunk/+pots/vlr/fr/5/+translate
[2] 
https://translations.launchpad.net/avaneya/trunk/+pots/vlr/fr/6/+translate