I'd like to have .po-file without path-comments (location). Our team has because of them a lot of trouble during git-merge.
I can get the file without comment using command:
$ xgettext --no-location -o input.po output.po
BUT! It removes headlines in the file beginning as well. Without those headlines PoEdit does not work correctly.
How can i remove all path-comments but store headlines in *.po file?
You answered your own question: use --no-location.
--no-location does not remove the gettext header (which you probably mean by "headlines"). It would make no sense for it to do it and Poedit itself uses it for its own PO(T) file(s).
Your problem is in your command — read xgettext manpage, it is for extraction from source code, not manipulating existing PO files (that's what msgcat is for).
Related
Is there a way to have comments in a _CoqProject file?
I'd like to compile only part of a library, without completely removing all the other files from the _CoqProject file.
# is treated as a comment-the-rest-of-the-line symbol.
I think it is not documented as of now (see issue #7647). But the source code and some experiments show that it works.
I am having a huge .tgz file which is further structured inside like this:
./RandomFoldername1/file1
./RandomFoldername1/file2
./RandomFoldername2/file1
./RandomFoldername2/file2
etc
What I want to do is having each individual file extracted to standard output so that I can pipe it afterwards to another command. While doing this, I also need to get the RandomFoldername name and file name so that I can deal with them properly from within the second command.
Till now the options I have are
to either extract all of the tarball and deal with the structured files that I will be having, which is not an option since the extracted tar doesn't fit into the hard drive
Make a loop that pattern match each file and extract one file at time. This option although that solves the problem, is too slow because the tarball is sweeped each time for only one file.
While searching on how to solve this, I've started to fear that there is no better alternative to this.
Using tar the tool I don't believe you have any other options.
Using a tar library for some language of your choice should allow you to do what you want though as it should let you iterate over the entries in the tarball one-by-one and allow you to extract/pipe/etc. each file one-by-one as necessary.
Did a MediaWiki upgrade from 1.15.1 to 1.20.2 by following the simple update instructions (basically a new installation, copying over the old LocalSettings.php, update script and copying over images). Weird thing now is that all of the File: prefixes don't work. Instead the internal links to images is a "file:name of image" URL rather than "http://mediawiki address/index.php/File:name of image".
Anybody else getting this. Assuming it is something wrong with the old LocalSettings.php.
Ran the refreshLinks and refreshImageMetadata maintenance scripts without fixing the problem.
In the comments, you wrote that you have file: added to $wgUrlProtocols. This is very likely what's triggering the problem.
It looks like something has changed in the parser between MW 1.15 and 1.20 so that it's now parsing file:whatever as an external link (since it matches the file: prefix you've defined in $wgUrlProtocols) even if it's inside square brackets.
The obvious workaround would be to change the $wgUrlProtocols entry from file: to file:// so that it will only match if the slashes are there (as they should be, according to standard file: URL syntax). Since your on-wiki filenames are, presumably, very unlikely to begin with double slashes, they should not match this more specific prefix.
That said, this could still be considered a bug in MediaWiki. You may want to file a bug report about it, if there isn't one yet.
(Edit: Looks like Mark A. Hershberger filed one already.)
With gettext, the original (usually English) text of messages serves as
the message key ("msgid") for the translations. This means that every time the
original text changes, the msgid must be updated in all the .po files.
For real changes of the text, this is obviously unavoidable, as the
translator must update the translation.
However, if the change of the original does not change its meaning,
re-translation is superflous (e.g. change in punctation, whitespace
changes, or correction of a spelling mistake).
Is there a way to update the .po files automatically in that case?
I tried to use xgettext & msgmerge (with fuzzy matching turned on), but
fuzzy matching sometimes fails, plus this produces lots of ugly
"#,fuzzy" flags.
Note: There is a similar question:
How to efficiently work with gettext PO files when making small edits to large text values
However, it's about large strings, thus about a more specific problem.
One way to avoid the problem is to leave the msgids alone, have a .po file for the original language and make the fix inside that.
It always strikes me as being more of a work around than a proper fix though. For the next iteration (where there will definitely be more msgid changes) the msgid is changed and either the translators translate it in their usual update or each language is updated by hand when the msgid is changed.
I've had exactly this issue when doing minor changes to a django project. What I do is the following:
Change message in code.
Run find and replace on all translation files ("django.po"), replacing the old message (msgid) with the new one.
Run django-admin makemessages.
If I have done things right, the last step is superflous (i.e, you have done the change for gettext). django uses the gettext utilities, so it shouldn't matter how you make your message files.
I find and replace like so:
find . -name "*.po" -print | xargs sed -i 's/oldmessageid/newmessageid/g' Courtesy of http://rushi.vishavadia.com/blog/find-replace-across-multiple-files-in-linux
/* $Id: file.c,v 1.0 2010/09/15 01:12:10 username Exp $ */
I find this line in many source code files in the comment at the top (header) of the file. Why? Is it aimed for the version control software? -Thanks.
These sort of comments are automatically modified by various source code control systems, things like author, date, history and so forth.
See here for some common ones for RCS which is the first source code control system I ever saw to implement this sort of thing (that doesn't mean it was the first, just that RCS was the first I ever used and it had that capability).
One particular trick we used to use was to put the line:
static char *fileId = "$Id: $";
into the source file (and header files as well, although the names had to be unique) so that, when it was built, it would automatically have the ID of the files in the executable itself.
Then we could use something like strings to find out which source files were used to build the executable. Ideal for debugging problems in the field.
It tells CVS (and other VCSs) to expand the value of the Id at check-out time, so anybody reading the source file in question will know what version exactly was checked out for it. Not very popular any more (you can always ask your VCS for such info if you keep the source file in a client / repository / working directory -- or however else your VCS calls such things;-).
I believe you are correct. It appears to be a keyword substitution string for CVS.
Take a look at this question $id: name of file, date/time creation Exp $