I'm sure there's a quick answer but I just cannot find it. Search engines don't get me any results when I put ">" or "greater than" and I've also searched the typoscript reference. I need to know what page.999 > does in a root template?
This is the object unsetting operator, see the TypoScript syntax documentation:
This is used to unset an object and all of its properties.
Well let's just say you have a CSS file that is coming from an Extension. Let's take the tx_news as example.
The tx_news, if you include the static template, gives you a CSS file on the header area of your html with the name news-basic.css. If you want to keep the static template in and remove the CSS file, this is the operator you use. ">"
For example:
plugin.tx_news.settings.cssFile >
At this point you say "Please remove the CSS file, i do not need it". Whatever the setting cssFiles holds, just remove it.
The same happens to you page.999. The page.999 holds something in it. With the ">" operator, you remove it. (at least in frontend).
On the other hand, if you use the "=" operator, you define a new file. Like this:
plugin.tx_news.settings.cssFile = EXT:myExtension/Resources/News/Resources/Public/Css/news.css
And with this operator < you append something on the cssFile
plugin.tx_news.settings.cssFile < lib.pathToTheFile
Best regards,
Related
I have a comma below my footer on a Gatsby site and I cannot find its source. It is at the end of the wrapper div with id "___gatsby". I have searched all component files and a bunch of other files to no avail. Going through all previous Git versions to find the change would be very burdensome at this point. Perhaps someone has an idea, based on the DOM structure below, where to best search for the comma?
Thanks.
I found it.
It turns out that a rogue character in gatsby-browser.js, in this case a comma after a closing tag, will be added in this way to the end of the #___gatsby div. In this case I overlooked the comma even through search because the comma was at the end of a long line of code and so did not appear visually in the search results list.
Use the find & replace functionality (or even just find) of your IDE/text editor and use the following regular expression:
\s,|,\s,
Here you have a working example of that regex: https://regexr.com/6hogi
I need to embed codelabs into an existing web site.
So, I need to change the actual HTML output (I need to get rid of etc.)
In claat's own help I see:
Note that the built-in templates of the formats are not guaranteed to be stable.
They can be found in https://github.com/googlecodelabs/tools/tree/master/claat/render.
Please avoid using default templates in production. Use your own copies.
To use a custom format, specify a local file path to a Go template file.
More info on Go templates: https://golang.org/pkg/text/template/.
Except that:
The link provided is very API-ish
The only command line option that mentiones templates is this:
-extra string
Additional arguments to pass to format templates. JSON object of string,string key values.
What do I actually need to do to pass claat a different template?
As the help message implies, use the format option. html or md are merely shortcuts to use the built-in templates.
claat export -f [template filepath] [source filepath]
Also was trying to solve this a year after it was first asked. It doesn't say explicitly, but digging into the source we can find where the format option is parsed.
https://github.com/googlecodelabs/tools/blob/main/claat/render/template.go#L166
Following that, we can specify our own html or text template file (relative or absolute path) with the -f option, instead of the default html or md format option (loading built-in templates).
These templates are parsed according to:
https://pkg.go.dev/html/template
https://pkg.go.dev/text/template
as the help message indicates.
I want to put keywords and comments in my source file.
the keywords documentation for gettext says: if keywordspec is of the form ‘id:argnum...,"xcomment"’, xgettext, when extracting a message from the specified argument strings, adds an extracted comment xcomment to the message.
I couldn't find any samples to help me with this.
This is my X-Pedit-KeywordsList header,
"X-Poedit-KeywordsList: __;_ex;\n"
And this is a sample line in my php source code:
_ex("unlock_level", "Available at level #.")
I expect the output to be:
# "Available at level #."
msgid "unlock_level"
How should I edit my keywordslist header (and/or the source)?
An example for the keyword spec (bourne shell syntax!) is:
xgettext --keyword='_ex:1,"my comment"' so.php
Unfortunately, this is not what you want. It produces this po entry:
#. my comment
#: so.php:3
msgid "unlock_level"
msgstr ""
The above command-line translates to "extract the first argument all all calls to _ex() as the msgid, and always add the comment 'my comment' to the PO entry". You can only specify which arguments are the singular, the plural, or the message context.
The X-POEdit-KeywordsList seems to be a custom header used by POEdit. It doesn't help you either.
You can kind of achieve the desired result by changing your sources to this:
<?
# TRANSLATORS: Available at level #.
_ex("unlock_level");
?>
Now invoke xgettext like this:
xgettext --add-comments=TRANSLATORS: --keyword=_ex so.php
You get this PO entry:
#. TRANSLATORS: Available at level #.
#: so.php:3
msgid "unlock_level"
msgstr ""
The option --add-comments=TRANSLATORS: has the effect that it adds comments that immediately precede a keyword iff that comment starts exactly with the string "TRANSLATORS:". You can exchange "TRANSLATORS:" with a string of your choice. You can also omit the argument to --add-comments and extract all comments that immediately precede keywords.
Not quite what you originally wanted but as close as you can get.
Poedit supports translator comments. I ended up adding localization keys to my source file like this:
// TRANSLATORS: "Available at level #."
__("unlock_level")
And this is what I get in my po file by pressing the update button in Poedit:
#. TRANSLATORS: "Available at level #."
msgid "unlock_level"
I just came across this post because I was also looking for a way to do this, and just wanted to add that #Paiman Roointans' solution works because PoEdit uses the TRANSLATORS: tag as default tag for comment extraction via gettext.
This can actually be seen if you open PoEdit -> Preferences -> Extractors, then click on the little "+" button at the bottom left of the window, which will show you the command PoEdit fires by default for an extraction of your translation strings from the source file, which is sth like:
xgettext -L PHP --add-comments=TRANSLATORS: --force-po -o %o %C %K %F
where %o %C %K %F are the respective placeholders, for example %o for the output filename, %K for the keyword list (you specify in POEdits keyword mask), etc.
To change the default comment identifier in PoEdit, simply go to Translation -> Properties -> Click on "Advanced Extraction Preferences" under de "Translation Properties" tab of the window which then pops up. Normally the first field there should tell you the current string being used as comment identifying tag. Change that for example to mysamplecommentkey, and write a translation like this in your PHP code, for example:
/* mysamplecommentkey: This is a test */
gettext( "Translate Me" );
And your "Translate Me" will have the This is a test comment attached to it when extracting from the source code.
And, just another point: You should rather use a POT instead of a PO template file for your gettext localizations in PoEdit. Set all of your keyword extractors and / or comment identifier string, then extract from your source code into your .pot file, everytime when you update your translations.
Then, in all of your PO files, you simply hit update from POT-File in PoEdit, and it will correctly update all of your translations, including all of the comments for translators, which will all be drawn from the POT file directly too (so you better write these translator comments in a language that all of your translators most likely understand).
It took me some time to figure all of this out, and I would have saved tons of hours if I knew all of this from upon the beginning, so I wanted to share this here. If used correctly, PoEdit (already the free version of it) can save you a lot of time!
The coding guidelines of programming language limit the line length, e.g. to 80 characters. How can I add a URL that is longer than that limit to Doxygen comments? How do I tell Doxygen that multiple lines are to be joined to form the actual link?
Example:
##
# #file mycode.py
# #sa See the documentation: http://some.host.some.domain/and_here
# _we_have_a_very_long_URL_that_can_not_be_written_in_one_line
# _because_it_would_exceed_the_line_length_limit
The example above doesn't work, and it doesn't work either to end the lines with a backslash (the backslash is just copied to the documentation).
You can try it this way. It worked for me. However I'm not a 100% sure its going to work for you. Our IDE use whitespaces as indentation and not tabs. So when you break the line, hence the link, it might not work.
<a href="http://stackoverflow.com/questions/9098680/
doxygen-link-to-a-url-doesnt-generate-the-link-correctly">
link
</a>
You could use an alias to abbreviate the long URL, i.e.
##
# #file mycode.py
# #sa See the documentation: #longurl
and in the Doxyfile define
ALIASES = longurl="http://some.host.some.domain/and_here/..."
This is performing necromancy an old question. I am answering for C++ style comments. But, if you make you link in the form:
/**
* [link_text](http://foo.com/bar/baz/qux/wibble/flob?id=deadbeef123456789abcdefghijklmnopqrstuvwxyz)
*/
You can wrap that URL in the following ways and the generated HTML output will still contain a working anchor tag:
/**
* [link_
text]
(http://foo.com/bar/baz/qux/wibble/
flob?id=deadbeef123456789abcdefghijklmnopqrstuvwxyz)
*/
Obviously this might make the comment block less readable. But this gives you an idea of what is possible. The main things that are advantagious here are being able to put the URL on a separate line from the link text, and then being able to wrap it at least once after a /.
I do have some text sequences that are replaced by the SCM (Perforce in my case).
I do want to configure BeyondCompare to consider these sequences as unimportant differences in order to be able to ignore them when I compare files.
In my case it's about Python source files and the sequences are looking like
# $Id: //depot/.../filename#7 $
# $DateTime: 2010/09/01 10:45:29 $
# $Author: username $
# $Change: 1234 $
Sometimes these sequences can be outside comments, but even in this cases I would like to be able ignore these lines because they are not really changed.
You need to define a new grammar element (let's call it "SCM") and mark it as unimportant (see the tutorial here; choose "Basic" and make sure to check "Regular Expression").
The grammar element should be (if I interpret your examples correctly):
^.*\$(Id|DateTime|Author|Change):.*$
This will ignore any line that contains $Id:, $DateTime: etc.
If you only want to ignore lines that start with # $..., use
^\s*#s*\$(Id|DateTime|Author|Change):.*$
And if you only want to ignore stuff between $ (and treat everything else as important), use
\$[^$\r\n]*\$
or
\$(Id|DateTime|Author|Change)[^$\r\n]*\$
depending on whether you care about those keywords or not.
Beyond Compare's parser doesn't currently (v3/v4) support nested elements, so file formats grammars can't be used to mark an SCM sequence as unimportant for a specific file type if the text is already classified as a comment, string, etc.
Beyond Compare 4.0 added support for marking arbitrary text as unimportant across an entire comparison, separate from the grammar.
Load the files you're interested in
Click the Session Settings button (aka Rules w/ umpire icon) or use the Session->Session Settings menu item.
Switch to the Importance tab
Click the + button at the bottom of the Unimportant text list.
Add the plain text or regular expression to Text to find edit and check the Regular Expression checkbox if necessary. In this case the regular expression would be:
\$(Id|DateTime|Author|Change):.*\$
Click Ok.
By default these changes will only affect the current comparison. You can change the combobox at the bottom of the Session Settings dialog from Use for this view only to Also update session defaults to make it affect all future comparisons for all file types.