Extension structure

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Extension structure

Oscar Manuel Gómez Senovilla
I crosspost this because I think both ng are involved. I anybody knows
another interested group, please make a followup to it.

When I face an extension to see its structure and try to translate, many
times is a PITA. That's why I've filed
https://bugzilla.mozilla.org/show_bug.cgi?id=326956 about standarization
of files contents for better scripting.

I'm not adding more here now, depending on the opinions raised here. I'd
like to know more localizers and developers point of view about it.


Regards.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

flod
Oscar Manuel Gómez Senovilla ha scritto:
> I crosspost this because I think both ng are involved. I anybody knows
> another interested group, please make a followup to it.

Take a look here
http://www.babelzilla.org
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Ognyan Kulev
In reply to this post by Oscar Manuel Gómez Senovilla
Oscar Manuel Gómez Senovilla wrote:
> I'm not adding more here now, depending on the opinions raised here. I'd
> like to know more localizers and developers point of view about it.

IMHO Mozilla should have something like Debian's lintian
<http://packages.debian.org/unstable/devel/lintian> and automatically
reject (for AMO) uploads of extensions that fail kind of "policy", like
in Debian.

Regards,
ogi
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Axel Hecht
In reply to this post by Oscar Manuel Gómez Senovilla
Oscar Manuel Gómez Senovilla wrote:

> I crosspost this because I think both ng are involved. I anybody knows
> another interested group, please make a followup to it.
>
> When I face an extension to see its structure and try to translate, many
> times is a PITA. That's why I've filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=326956 about standarization
> of files contents for better scripting.
>
> I'm not adding more here now, depending on the opinions raised here. I'd
> like to know more localizers and developers point of view about it.
>
>
> Regards.


http://developer.mozilla.org/en/docs/Chrome should probably be more
verbose on
that, and linked from http://developer.mozilla.org/en/docs/Bundles.

(Calendar is just a bug that is about to get fixed.)

I don't feel any positive about not uploading extensions to AMO for
coding style reasons.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Rod Whiteley
In reply to this post by Oscar Manuel Gómez Senovilla
Oscar Manuel Gómez Senovilla wrote:
> ...standarization of files contents for better scripting...

If the installer can see where the locale files are, then so can your
script.  It only has to read chrome.manifest or go looking for
contents.rdf files.

A related problem is that translators so often hack the XPI instead of
working with source code.  The XPI is designed as an installation
vehicle, not as a source code package.

Perhaps it would be better to design a simple source code package
standard for exchanging files between developers and localizers, then
persuade Mozilla to use it for Mozilla projects.  Extension developers
would soon catch on, and tool sets would grow around it.

--
Rod Whiteley
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Oscar Manuel Gómez Senovilla
In reply to this post by Oscar Manuel Gómez Senovilla
Francesco Lodolo escribió:
> Oscar Manuel Gómez Senovilla ha scritto:
>> I crosspost this because I think both ng are involved. I anybody knows
>> another interested group, please make a followup to it.
>
> Take a look here
> http://www.babelzilla.org


Yes, the spanish moderator is a member of our team, and we started long
before babelzilla (just to "apologize").

This issue can grow very much, depending on the targets. Of course,
translating on line is an option (recent), but that doesn't remove the
earlier problem.


Regards.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Oscar Manuel Gómez Senovilla
In reply to this post by Axel Hecht
Axel Hecht escribió:

> Oscar Manuel Gómez Senovilla wrote:
>>
>> When I face an extension to see its structure and try to translate, many
>> times is a PITA. That's why I've filed
>> https://bugzilla.mozilla.org/show_bug.cgi?id=326956 about standarization
>> of files contents for better scripting.
>>
>
> http://developer.mozilla.org/en/docs/Chrome should probably be more
> verbose on
> that, and linked from http://developer.mozilla.org/en/docs/Bundles.


Well, I'm not a developer, and I don't know where the "faulty"
developers got the info, just echoing the results of what I've seen. If
those links are a kind of "MUST" for developers, it's a good start. But
I hope that nobody "powerful" enough is against it.


> I don't feel any positive about not uploading extensions to AMO for
> coding style reasons.


I didn't mean that, mainly because that's something out of my scope.
Besides, I've found the problem in extensions I downloaded from custom
sites.


Regards.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Oscar Manuel Gómez Senovilla
In reply to this post by Rod Whiteley
Rod Whiteley escribió:
> Oscar Manuel Gómez Senovilla wrote:
>> ...standarization of files contents for better scripting...
>
> If the installer can see where the locale files are, then so can your
> script.  It only has to read chrome.manifest or go looking for
> contents.rdf files.


The last time I looked for info about chrome.manifest, it was an
optional file. I don't know if in the future it's supposed to perform
part of the tasks that install.rdf does actually. Anyway, I think
installers succed because of what's in install.rdf.


> A related problem is that translators so often hack the XPI instead of
> working with source code.  The XPI is designed as an installation
> vehicle, not as a source code package.


For years (even now) we haven't had any other way to provide our
translations to the users. Maybe we're on the way, but it's still a long
way to get there.


> Perhaps it would be better to design a simple source code package
> standard for exchanging files between developers and localizers, then
> persuade Mozilla to use it for Mozilla projects.  Extension developers
> would soon catch on, and tool sets would grow around it.


I think all possibilities must be evaluated. What's more, maybe one
source, but not strictly just one tool or way to get the taks. Even even
more ;) important: many people are very good at translating, but don't
know (nor shouldn't need to) what a cvs, diff, installer or anything
else is.


Regards.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Axel Hecht
In reply to this post by Rod Whiteley
Rod Whiteley wrote:

> Oscar Manuel Gómez Senovilla wrote:
>> ...standarization of files contents for better scripting...
>
> If the installer can see where the locale files are, then so can your
> script.  It only has to read chrome.manifest or go looking for
> contents.rdf files.
>
> A related problem is that translators so often hack the XPI instead of
> working with source code.  The XPI is designed as an installation
> vehicle, not as a source code package.
>
> Perhaps it would be better to design a simple source code package
> standard for exchanging files between developers and localizers, then
> persuade Mozilla to use it for Mozilla projects.  Extension developers
> would soon catch on, and tool sets would grow around it.
>

There is a pretty well defined way to organize localizable source code,
set forth by toolkit and browser/mail. (Calendar not yet)

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Axel Hecht
In reply to this post by Oscar Manuel Gómez Senovilla
Oscar Manuel Gómez Senovilla wrote:

> Axel Hecht escribió:
>> Oscar Manuel Gómez Senovilla wrote:
>>> When I face an extension to see its structure and try to translate, many
>>> times is a PITA. That's why I've filed
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=326956 about standarization
>>> of files contents for better scripting.
>>>
>> http://developer.mozilla.org/en/docs/Chrome should probably be more
>> verbose on
>> that, and linked from http://developer.mozilla.org/en/docs/Bundles.
>
>
> Well, I'm not a developer, and I don't know where the "faulty"
> developers got the info, just echoing the results of what I've seen. If
> those links are a kind of "MUST" for developers, it's a good start. But
> I hope that nobody "powerful" enough is against it.

There seems to be a misconception on what documentation can do.
If you feel like evangelising for a particular packaging structure, feel
free to mail extension authors.

I doubt that those that use some odd structure just do what works, but
they sureley not "get info from somewhere". I blame old seamonkey code,
if any.

>
>> I don't feel any positive about not uploading extensions to AMO for
>> coding style reasons.
>
>
> I didn't mean that, mainly because that's something out of my scope.
> Besides, I've found the problem in extensions I downloaded from custom
> sites.
>

That was just as a reply to the other comment in the bug.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Ricardo Palomares Martí­nez
In reply to this post by Axel Hecht
Axel Hecht escribió:

> Rod Whiteley wrote:
>>
>> A related problem is that translators so often hack the XPI
>> instead of working with source code.  The XPI is designed as an
>> installation vehicle, not as a source code package.
>>
>> Perhaps it would be better to design a simple source code package
>> standard for exchanging files between developers and localizers,
>> then persuade Mozilla to use it for Mozilla projects.  Extension
>> developers would soon catch on, and tool sets would grow around
>> it.
>>
>
> There is a pretty well defined way to organize localizable source
> code, set forth by toolkit and browser/mail. (Calendar not yet)
>


Well, it's my impression that a system that uses a directory structure
in CVS that gets completely changed in the production JARs is
something that still leaves room for improvement.

I'm not denying that it works (the facts prove it), but all of us in
this NG should concede that setting up the CVS so the locale resources
were separated enough from the "real" code that translators could be
granted read-write access without developers fearing it hasn't been an
easy task. And if that's difficult for something like MoFo, it can't
be easier for an amateur extension developer, that maybe hasn't got
the knowledge or the required control on CVS to mimic MoFo structure.
Well, it must be not so easy if a bug like this:

  https://bugzilla.mozilla.org/show_bug.cgi?id=267981

has been opened for almost a year and a half for an extension that
"only" had to follow the way paved by Firefox and that already shared
the same CVS with toolkit and browser.

My point is that what is working (after a lot work, let's admit it)
for core Mozilla products may not be the best solution for all. Doing
a source localization process for small extensions may not be
practical for neither extensions authors nor translators. In those
cases, recommending/enforcing an XPI and JAR structure as much as
possible could only lead to better results for all parties involved.

In a slightly related topic, repackaging the chrome in a different
structure than the one in CVS poses a problem I'm not sure can be
handled by L10N tools (and, if it can be, I'd glad to know about it). :-)

Currently, brand.dtd is the only one I'm aware of that uses PE
references (IOW, that does kind of an "include" of another .dtd file).
Unfortunately, the system reference (the path to the file to be
included) is expressed as a chrome:// URL, ie., considering the
directory structure that the JAR will have, and not the one in the CVS.

However, if source localization is to be done, a consistent rule to
convert those URLs to some file:// that points to the actual file in
the CVS structure will be needed, otherwise requiring that every L10N
tool implements their own XML parser (impractical, to say the least).

As the progress in my final year project (a Mozilla L10N tool,
remember?) has been close to NUL, I haven't had yet to face this
problem, but I will surely have to (and I presume that any other L10N
tool that intends to parse the DTDs using a standard XML parser will
have the same problem). Any ideas will be welcomed.

Ricardo.

--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Oscar Manuel Gómez Senovilla
In reply to this post by Oscar Manuel Gómez Senovilla
Oscar Manuel Gómez Senovilla escribió:
> those links are a kind of "MUST" for developers, it's a good start. But
> I hope that nobody "powerful" enough is against it.


Can you believe it happened? The bug has been marked as WONTFIX with
this comment:

"I don't think it is possible or reasonable to enforce these arbitrary
standards on extension authors, or even on the tree."

I find "arbitrary" a very wrong term, unless it's considered arbitrary
the most widely used structure for years in mozilla development and that
is starting to break. I just intend to limit the flexibility degree, not
break any system.

I don't know if the problem is interesting enough for anybody else than
me, so maybe it's better to forget everything.


Regards.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Axel Hecht
In reply to this post by Ricardo Palomares Martí­nez
Ricardo Palomares Martinez wrote:

> Axel Hecht escribió:
>> Rod Whiteley wrote:
>>> A related problem is that translators so often hack the XPI
>>> instead of working with source code.  The XPI is designed as an
>>> installation vehicle, not as a source code package.
>>>
>>> Perhaps it would be better to design a simple source code package
>>> standard for exchanging files between developers and localizers,
>>> then persuade Mozilla to use it for Mozilla projects.  Extension
>>> developers would soon catch on, and tool sets would grow around
>>> it.
>>>
>> There is a pretty well defined way to organize localizable source
>> code, set forth by toolkit and browser/mail. (Calendar not yet)
>>
>
>
> Well, it's my impression that a system that uses a directory structure
> in CVS that gets completely changed in the production JARs is
> something that still leaves room for improvement.
>
> I'm not denying that it works (the facts prove it), but all of us in
> this NG should concede that setting up the CVS so the locale resources
> were separated enough from the "real" code that translators could be
> granted read-write access without developers fearing it hasn't been an
> easy task. And if that's difficult for something like MoFo, it can't
> be easier for an amateur extension developer, that maybe hasn't got
> the knowledge or the required control on CVS to mimic MoFo structure.
> Well, it must be not so easy if a bug like this:
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=267981
>
> has been opened for almost a year and a half for an extension that
> "only" had to follow the way paved by Firefox and that already shared
> the same CVS with toolkit and browser.
>

Let me say that this bug is talking about two extensions targetting
three applications (one of them not being based on toolkit) and one
application. Just Sunbird would have been a snap.

> My point is that what is working (after a lot work, let's admit it)
> for core Mozilla products may not be the best solution for all. Doing
> a source localization process for small extensions may not be
> practical for neither extensions authors nor translators. In those
> cases, recommending/enforcing an XPI and JAR structure as much as
> possible could only lead to better results for all parties involved.

I have created
http://developer.mozilla.org/en/docs/Writing_localizable_code which I
would welcome your comments on.

That page isn't hooked up well at all so far, as I expect it to mature a
bit still. A few more categories could be added, and we could link to it
from places that guide extension authors.

> In a slightly related topic, repackaging the chrome in a different
> structure than the one in CVS poses a problem I'm not sure can be
> handled by L10N tools (and, if it can be, I'd glad to know about it). :-)
>
> Currently, brand.dtd is the only one I'm aware of that uses PE
> references (IOW, that does kind of an "include" of another .dtd file).
> Unfortunately, the system reference (the path to the file to be
> included) is expressed as a chrome:// URL, ie., considering the
> directory structure that the JAR will have, and not the one in the CVS.
>
> However, if source localization is to be done, a consistent rule to
> convert those URLs to some file:// that points to the actual file in
> the CVS structure will be needed, otherwise requiring that every L10N
> tool implements their own XML parser (impractical, to say the least).
>
> As the progress in my final year project (a Mozilla L10N tool,
> remember?) has been close to NUL, I haven't had yet to face this
> problem, but I will surely have to (and I presume that any other L10N
> tool that intends to parse the DTDs using a standard XML parser will
> have the same problem). Any ideas will be welcomed.

As you can see in the page above, I'm a strong advocate to keep down the
requirements on hacks due to mozilla code practices to a minimum.

That does not appy to trademarks relevant files, which I hope to reduce
and isolate, as those can be made much more easy with some build logic
than by going through a localization and review process. This is really
a compromise, and I'll swing from side to side constantly.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Oscar Manuel Gómez Senovilla
Axel Hecht escribió:
>
> I have created
> http://developer.mozilla.org/en/docs/Writing_localizable_code which I
> would welcome your comments on.
>
> That page isn't hooked up well at all so far, as I expect it to mature a
> bit still. A few more categories could be added, and we could link to it
> from places that guide extension authors.


Thanks, Axel. That's about a 95% of what I was asking for. It's a pity
some people don't think this way.


Regards.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Ricardo Palomares Martí­nez
In reply to this post by Axel Hecht
Axel Hecht escribió:
>
> I have created
> http://developer.mozilla.org/en/docs/Writing_localizable_code which I
> would welcome your comments on.
>


It looks really nice. It could be the perfect place to suggest a
consistent way to name commandkeys and accesskeys entities, something
like this:


>  Choose good key names
>     The names chosen for your keys (...)

  Be consistent with shortcuts and accelerators key naming

Many times you will define a key for a UI element (ie. the label for a
button, a checkbox or a menu option) that can be accessed with a
keyboard accelerator (ie. 'Paste' menu option inside the Edit menu has
'P' accelerator) or a shortcut (ie. Edit -> Paste can be executed by
pressing [Ctrl]+[V]). Try to be consistent when naming the entities
for a label and its associated accelerator ("accesskey") and shortcut
("commandkey"). Example:

 - <! ENTITY editpaste.label "Paste" >
 - <! ENTITY editpaste.accesskey "P" >
 - <! ENTITY editpaste.commandkey "V" >

---------


I'm not really sure than "Use a good source directory structure" is
clear for everyone. I think you're saying to developers to put .dtd
and .properties in a directory tree outside the one containing the
actual code (.c, .xul, .js...). But I can't say it for sure. Is anyone
else having the same doubt?

All in all, a valuable document which all of us should contribute to
and reference whenever appropiate, to let it others to be aware of it.
Thanks a lot, Axel.

Ricardo.

--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Extension structure

Axel Hecht
Ricardo Palomares Martinez wrote:

> Axel Hecht escribió:
>> I have created
>> http://developer.mozilla.org/en/docs/Writing_localizable_code which I
>> would welcome your comments on.
>>
>
>
> It looks really nice. It could be the perfect place to suggest a
> consistent way to name commandkeys and accesskeys entities, something
> like this:
>
>
>>  Choose good key names
>>     The names chosen for your keys (...)
>
>   Be consistent with shortcuts and accelerators key naming
>
> Many times you will define a key for a UI element (ie. the label for a
> button, a checkbox or a menu option) that can be accessed with a
> keyboard accelerator (ie. 'Paste' menu option inside the Edit menu has
> 'P' accelerator) or a shortcut (ie. Edit -> Paste can be executed by
> pressing [Ctrl]+[V]). Try to be consistent when naming the entities
> for a label and its associated accelerator ("accesskey") and shortcut
> ("commandkey"). Example:
>
>  - <! ENTITY editpaste.label "Paste" >
>  - <! ENTITY editpaste.accesskey "P" >
>  - <! ENTITY editpaste.commandkey "V" >

I added that to the talk page for now, but I intended to add that, yes.

I need to find out where in our other xul docs this is, and cross
reference that. http://www.mozilla.org/access/xul-guidelines and
http://www.mozilla.org/access/keyboard/accesskey should probably be
hooked up vice versa, too.

>
> ---------
>
>
> I'm not really sure than "Use a good source directory structure" is
> clear for everyone. I think you're saying to developers to put .dtd
> and .properties in a directory tree outside the one containing the
> actual code (.c, .xul, .js...). But I can't say it for sure. Is anyone
> else having the same doubt?
>
Yeah, I should clarify that a bit.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n