Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add mimetype for gettext translation files #98

Closed
ronkorving opened this issue Jul 29, 2014 · 8 comments
Closed

Add mimetype for gettext translation files #98

ronkorving opened this issue Jul 29, 2014 · 8 comments

Comments

@ronkorving
Copy link

Currently there's no content-type in the list for gettext translation files (.po).

@broofa
Copy link
Owner

broofa commented Aug 14, 2014

This is the first request I've seen for this, so I'm guessing it may not be in high demand. Consider using define() or load() to define this for your project?

@broofa broofa closed this as completed Aug 14, 2014
@yanickrochon
Copy link

Gettext files are usually used by servers and are not downloaded... however, here is the information for it.

Basically : text/x-gettext-translation for .po extensions.

@broofa
Copy link
Owner

broofa commented Aug 14, 2014

@yanickrochon - are you saying this should or should not be added to node-mime, or just making a general comment?

Re: these files being used by servers, that's always been an interesting use case to me. I generally think of mime types as being most useful in the world of browsers, where the mimetype drives the action subsequent to downloading (e.g. save to disk, open in browser window, open in external app, etc.) But typically a server-acting-as-a-client would seem to be much more directed in what it's willing/able to do with a file... i.e. less sensitive to mimetype. But I could be wrong there... I'd love to hear examples of how server-side mimetypes matter. :-/

@yanickrochon
Copy link

@broofa yes, that was general comment. I also see mime types as a "context" to a downloaded context (i.e. what is it, and how it should be handled?). Gettext is almost never, if not ever, downloaded and/or used on the client side, therefore debating whether it should or not be added to the list is somewhat arbitrary.

That being said, someone might find this useful if they are working on some kind of "online gettext editor" or something. I don't see a particular reason to add it, but then again, I also don't see a reason why not. After all, there are some mimes there that I've never heard my entire life!

@broofa
Copy link
Owner

broofa commented Aug 14, 2014

"why not"

Anywhere node-mime diverges from what Apache is doing creates a risk that Apache may later add or change support in a way that breaks things. Ideally, I'd really like node-mime to stay out of the business of dictating mappings and leave that sort of thing to Apache, but that's not always feasible. But having a reasonably compelling reason to add a type is always nice. (However I'll be the first to admit that the decision making around what has / hasn't gone into node.types has been rather arbitrary. :-/ )

@yanickrochon
Copy link

Well, I'm just advocating here, I have no use for this mime type and, if someone really needs it, it can be defined quite easily. As for the Apache part, they're so taking their darn time to change anything that I doubt anything would break any time soon. After all, standards are not defined by corporations, but by those who needs them.

@ronkorving
Copy link
Author

Wow, this really stirred up an interesting conversation. I can live without it, no worries (by all means, keep this issue closed). As far as the use-case for mime types...

Mime-types are useful whenever you're dealing with file content without a file name. HTTP downloads are the most common case of that, but it's definitely not the only case. HTTP is just one protocol.

@sujeet187
Copy link

Gettext files are usually used by servers and are not downloaded... however, here is the information for it.

Basically : text/x-gettext-translation for .po extensions.

thanks its working !!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants