Need a place to host localizations for Penelope

RESOLVED FIXED

Status

Mozilla Localizations
Infrastructure
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: Jeff Beckley, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
The Penelope project, <https://wiki.mozilla.org/Penelope>, was created to help migrate Classic Eudora users over to using Thunderbird.  It's an extension to Thunderbird that provides the look and feel of Eudora, and some of Eudora's features.  The source code for Penelope is kept in <http://hg.mozilla.org/penelope/>.

It would be nice to get localizations of Penelope in to other languages.  Rimas Kudelis <rq@akl.lt> has already created localizations in to Lithuanian.  Could a place to store these localizations get created in the standard l10n-central repository?

Thanks!

Comment 1

10 years ago
Mike, Seth, what's your take on this?

I'm not sure how to handle this, and how much of a precedent we're setting here. And how many other similar projects we're having flying around.

One the one hand, having more content up isn't evil, on the other hand, we're adding noise to mxr searches, to pushlog queries, and other things.

Comment 2

10 years ago
I think l10n-central/ab-CD/extensions/penelope/ would be a very good place to store these files.

At least for a "team" like me alone, this is the best option. I certainly don't want to remember a yet another way or policy to commit my translation somewhere, and I prefer to be able to check my strings in myself whenever I spot a problem instead of filing a bug on a product and waiting for the developer to find some time to review and commit my patches.

I don't remember if it's possible to define directory specific rights for the hg user, so probably the biggest downside of this "all in one repo" approach is a possible mess that bigger teams would have to deal with.

Comment 3

10 years ago
This is really less of a question of directory structure, and more of "which projects should have their localization data on l10n-central".

Permissions is not my primary concern either, it's more about noise.
I can go either way, but if it needs any attention from build to set up, it'll probably starve a little while since they're slammed.

Seems like someone from TB should be involved here, maybe Simon?
(Reporter)

Comment 5

10 years ago
I'm okay with any place to put these files.  I just want to make it easy for localizers to work on it, and use as much of the standard process and locations as possible.  I mentioned l10n-central because that's where Pike suggested they should go.

In terms of builds, there is nothing needed from the l10n community to support that.  I handle all builds of Penelope myself, and will do all the work to ensure that Penelope localizations are included with Penelope releases.

Comment 6

10 years ago
(In reply to comment #3)
> This is really less of a question of directory structure, and more of "which
> projects should have their localization data on l10n-central".

Well, my opinion is that if a project itself is already hosted on mozilla's servers, and especially if it is closely related (maybe "dependent" would be a better word here) to our other projects (like Thunderbird, in this case), it shouldn't be a problem to host its localization files on l10n-central repos.

> Permissions is not my primary concern either, it's more about noise.

I think the noise problem is being addressed on bug 448709... :)

Comment 7

10 years ago
This discussion has been silent for more than a month now. Could we have a definite answer somehow?

Also CC'ing sipaq per Mike's suggestion.

Comment 8

10 years ago
IMO the decision was already made when Penelope was allowed to be hosted on mozilla.org cvs server in mozilla/penelope.

Now it's on hg in its own repository and I see no reason, why localizations shouldn't be hosted in l10n-central as well. IMO Rimas' proposal to host it in l10n-central/ab-CD/extensions/penelope/ sounds good.

This shouldn't be held up by a small technical problem (bug 448709), which hopefully will be fixed soon.

Comment 9

10 years ago
Who should make the final decision on this? Can I already upload my translation to extensions/penelope/, or not? And if not there, then where do I upload it?

Comment 10

10 years ago
Finally had a chat with shaver.

I'm pretty sure if l10n-central is a not the best option for penelope in the first place. There are no really working other extensions, and the fact that hg doesn't allow partial clones is going to make pulling their l10n files from l10n-central icky.

I suggest to either have IT grant hg write access for localizers to the penenlope repository, or to use independent hg repositories, either on localizers hg user repos on hg.m.o or mozdev.org or wherever they want to host it for cloning via http.

Both options allow the penelope guys to have more freedom on how to get their locales into their builds.

Comment 11

10 years ago
(In reply to comment #10)
> I'm pretty sure if l10n-central is a not the best option for penelope in the
> first place. There are no really working other extensions,

Well, I clearly see respective directories for venkman and reporter under l10n-central/pl/extensions/, for example.

> and the fact that hg doesn't allow partial clones is going to make pulling
> their l10n files from l10n-central icky.

I think this was about to be solved in the next version of Mercurial, no?

Furthermore, since without Thunderbird Penelope isn't functional, I don't see a problem in pulling more files than actually needed for this addon.

I especially don't see this overload as something unique to Penelope's situation, considering that to translate e.g. Thunderbird, I'm now supposed to pull full sources of Thunderbird, SeaMonkey, and Firefox (that makes 700+ MB) instead of just language files.

And one more argument: since Penelope is basically a mod for Thunderbird, and has really very few strings, I think it would be beneficial for both products if the same localizer (or same team) would work on localizing them. And the biggest chances for that to happen are when the localized files reside at the same place.

> I suggest to either have IT grant hg write access for localizers to the
> penenlope repository, or to use independent hg repositories, either on
> localizers hg user repos on hg.m.o or mozdev.org or wherever they want to host
> it for cloning via http.
> 
> Both options allow the penelope guys to have more freedom on how to get their
> locales into their builds.

Actually, the only potential real problem that I just came up with is perhaps desynchronized schedule between releases of Tb and Penelope. However, I'm still unsure whether that would be a problem or not (I guess it would not though).

Sorry for being insistive, but I still think l10n-central/ab-CD/extensions/penelope/ is a good place...

Comment 12

10 years ago
I claim that neither Venkman nor DOMI work. Just their files being there doesn't say that they're working. And neither reporter nor spellcheck are extensions, despite them being in a directory that says so.

Partial pulls are obviously not going to get solved, the SOC project for that didn't succeed, due to that just being really hard. Which forces the penelope guys to work around that by doing something utterly cumbersome in one way or another, for no technical reason.

The mumbling about the same people doesn't hold water either, as anybody with write access to l10n-central can already create user repos, as described at https://developer.mozilla.org/en/Publishing_Mercurial_Clones.

Comment 13

10 years ago
OK, then it's up to Jeff now, I guess.
(Reporter)

Comment 14

10 years ago
Like I said in comment 5, I'm fine with whatever spot is decided on to hold the localizations.  I would just like it to be as easy as possible for Penelope localizers to make their changes.

Comment 15

10 years ago
Jeff, so, now you get to choose from the options suggested in comment 10, or come up with your own.
(Reporter)

Comment 16

10 years ago
I'm not versed in the process of localization, so I don't think I'm necessarily the best one to make that decision.  In my naive view, I think allowing write access for localizers to the penelope hg repo would be good.  That way there's nothing a localizer has to set up on the server side to contribute.  That method also winds up being the easiest for me, because then the locales are already in place, but I don't want ease-of-use for me to be the driving factor (although it could be the deciding factor if all other solutions are deemed equivalent).

Comment 17

10 years ago
Well, if that's fine with you, it's fine with me too. It's certainly much better than emailing those files or filing bug reports for each l10n update.

You should contact IT, as suggested in comment 10 then.

Comment 18

10 years ago
I assume this is fixed by now? Marking as such.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

8 years ago
Well, we've just been using the Penelope repo for localizations.  That was working fine until recently RQ had problems submitting to it.  Don't know if he got that resolved or not, RQ?

Comment 20

8 years ago
Jeff, I think we'll figure it out whenever I have something to commit. I don't to submit dumb changes like test files just to figure that out. And I think it's quite likely that it would work after all.
You need to log in before you can comment on or make changes to this bug.