connector l10n_drupal scans only for .tar.gz files but not for .tgz (also a valid tar file extension)

Well, I'd patch the feature server. Drupal.org does tar.gz files, and since all the rest of the filename is parsed according to rules of file naming on drupal.org (project name, version number placement, separator chars, etc.), let's keep that file standard. If features servers are not conforming to that, then it should be fixed there.

I still don't think we should deviate from the drupal.org guidelines... Also your code comment changes show scary things like "drupal-6.x-6.19.tar.gz" which are not at all valid on drupal.org either.

hi,

i checked the patch and except for the wrong drupal - package name ;-) it's totally ok.

Why should this patch be accepted?

Also Gabor stats in #1 the default extension should be .tar.gz, it is not a mistake imho to also accept .tgz (which are common in the rest of the world).

Since the change is small and does not hurt anybody, i only see the improvement.

Best
Thomas

I can certainly modify the localization server to export as tar.gz for consistency.

Not sure how you got to the generalization of simple patches refused wholesale. No reason to take it personal.

I'm trying to keep the module as simple as possible, even though it did grew quite big already. The goal of the drupal connector is to support stuff as distributed on drupal.org. Any more added complexity (such as adding 30 more lines to support something not done on drupal.org) makes it overcomplicated. I'm not even sure why you suggest adding this many code merely to support yet another extension?!

I don't believe in adding all kinds of nice things just because they are simple to add, but I do believe in enabling people to do so. In this case, the file scanning pattern is not really accessible from the outside of the module for modification, so I understand the frustration. In fact, drupal.org does not have any use for this piece (that is l10n_drupal.files.inc), so we can easily spin it off to its own module, whoever can maintain it and can add whatever they want. No reason to complain then for the project not being open enough to expand beyond the scope that it was intended for by the maintainer. Deal?

Ps. one of the other things slated for removal from the l10n_server package is in fact the exporting of compressed files, which is yet another thing we are not going to use and encourage on drupal.org. So that it does not use the drupal.org standard tar.gz extension will be possible to be remedied by those, who have the need for this functionality and come forward with an extension module to make it work that way.

I'm happy to suggest drupal.org hosted extension modules to l10n_server on its project page, so far nobody felt the need to write their additions, you can be a first!

To be seriuos, the code size argument is by FAR the most flaky one.

Looking at the curren code, really, there is no single positive argument in quality or size. It seems like the author is in love with regular expressions and never even got near to the fact that "if you solve a problem with a regexp, you have 2 afterwards".

The code is far away from being
- maintainable
- readable
- optimal
- bug free
- extendable

and seeing you denieing a patch which does it a _lot_ better is really makes it a lot easier to
- read
- extend
- maintain

without changing the yet default behaviot.. well pretty dissapointing - nothing more.

You are wasting potentials here - and effort.

The code of l10update client and server can need a lot of more love, and i admit, you cant do it all on yourself. But dont wonder if you wont get to much help.

Once again I'd like to extend my offer of breaking out the drupal.files.inc connector to its own module. There our outstanding feature requests in the queue for it, so it can grow and blossom as its own module. There is no need to follow "my rules". My thinking about it is that it should support what is on drupal.org, as it does. You can take it forward if you want for the benefit of all who use l10n_server to translate Drupal code but not on localize.drupal.org. Forgive me for working with the drupal.org patterns, that is where my focus is.

Ps. as said above, exporting as packages is also about to be phased out from the server, so possibly having a more generic addon package with these features for people who need them would be useful then.

Subscribing.

Hi, I don't think this issue is valid anymore, right? I'll mark it as closed just to cleanup the queue since drupal.files.inc has been moved to its own module in 6.x-3.x.

Please change it back if it still applies.

Hm, i do not understand comment #13:

Sorry, there is no progress in just closing an issue without being sure, that it is solved or decided.
(I think every issue is not solved until this is proved.)

So let the issue open until it is in a traceable way solved or decided.

If you are in doubt:

http://drupalcode.org/project/l10n_server.git/blob/refs/heads/6.x-3.x:/c...

you find:
// Packages are always .tar.gz files.
$files = file_scan_directory($workdir, '.tar.gz$');

so tgz is still not included.

Added an issue and a patch to Fserver to get that to output tar.gz packages.

This is the solution to 1) in the original post (and I happen to agree with Gábor Hojtsy in #1 that Fserver is the right place to fix this). But just wanted to share my solution to the problem of getting Fserver and Localization server working together.

Len

d.o has only tar.gz and zip.