As far as i could dig in thought google, i found something like:
<languages>
<language tag="en-GB">en-GB.whatever.ini</language>
<language tag="en-GB">en-GB.whatever.sys.ini</language>
</languages>
From here some question:
Can i use it without tag and somehow specify to use with the default system language
What is the difference between whatever.ini and whatever.sys.ini
Do I have something else to write to xml or those 4 lines uploads and runs languages
The tag="en-GB" is required.
.ini contains ALL the translations including the description for an extension when it it opened up in the Module or plugin Manager....sys.ini is used to define the description of the extension upon installation.
The code you provided in the XML is fine ;)
Related
I like to add additional macros to asciidoctor for these types:
path:[some path value]
label:[some label text]
replace:[some value to become replaced by the user]
screen:[something the users sees on screen]
I mainly want to have it rendering some CSS classes while rendering to HTML5. I found several sources on how to write a macro for asciidoctor, but I do not get the point. Where to place or insert the ruby code and classes I write? Here is an example page I found: https://docs.asciidoctor.org/asciidoctor/latest/extensions/inline-macro-processor/
But I found no simple step-by-step information about where to place that?
Can someone tell me:
In which file(s) shall I add my macro code?
How to enable this in general for asciidoctor (so I can simply call it without the need to put it into the comandline call. Or do I have to register the macro in the call all the time?
I installed asciidoctor on Ubuntu 20.04 using apt-get install asciidoctor. Seems it works so far. But I found no files for the predefined macros btn, kbd and menu.
I'm a little lost here... Any help is appreciated.
PS. I know the syntax [.label]#some label text# to place CSS classes, but I want to have it generic and also usable for PDF generation later.
After many different tries and research I finally found it to be easy. Just point asciidoctor to the file you want to include by using the -r comandline parameter:
asciidoctor -r ~/tools/asciidoctor_patch/include_asciidoc.rb
Sadly, the whole asciidoctor documentation names this parameter only "require" and does not even mention this to be used for extensions. I also found no source that mentions the use of -r for including the macros.
I'm learning Go but I can't find this answer anywhere. Is there any official standard for file extensions in web development? I've seen multiple conventions like .tmpl and .gtpl, which is what? Thanks.
There's no fixed standard, but there are some fairly common practices. For templates on web projects, I use the extension appropriate for the type of file it is, e.g. .html, .css, etc. That's what's done in the widely-read-and-cited Writing Web Applications blog post on the official Go blog, which makes it fairly standard. I find it useful for easy syntax highlighting without changing my editor's settings/config, and processing by other tools. I put these templates in a /templates/ directory to keep them separate from non-template files.
I've seen and used .tmpl before, it's in official docs for both html and text template packages, which makes that fairly standard too, and I think it makes sense if you're making a file-type-agnostic template, or you don't have any associations that are useful by more specialized file type.
For Go code files, I always use the .go extension, which works well with the Go toolset. It's what you generally see in official Go documentation, such as this introductory document on How to Write Go Code. For executables, I don't append any file extension. The default result when you go build <name>.gois an executable called <name>, and so that makes it a common practice.
I would like to use Zend Translation to translate my app into various languages. The problem I face is finding a tutorial that explains how to set it up clearly and without any ambiguity.
This is what I currently have:
In the language file I have:
And in my view I am calling:
<?php echo $this->translate('Skeleton Application') ?>
And I am expecting the output: "hello"
Instead the text: "Skeleton Application" is returned.
Now I assume I need to do some configuration to set this all up such as setting locale etc. However, I can not find any documentation on this or what to do and where...
In Application.Config.php the following modules are included:
Zend\I18n',
'Zend\Mvc\I18n',
Any help on this would be great!
You have everything setup right. Both modules are indeed required as one is the actual translator, and the other one is the integration in Zend MVC (view helpers and all).
In terms of what's not working, it is not ZF related, but rather po/mo related. The translation file you are editing is the .po file, the human readable format, which then needs to be compiled into a .mo file, a binary that is going to be used by your system.
In your specific case, you are missing the compilation to binary step, hence the value not changing (as the .mo file has not changed).
You can either use a command line tool for that compilation, or use a tool such as poeditor on you machine to edit your translation files.
When working with Nunjucks templates which requite rendering or compilation is there a standard naming convention to be used to have them processed? i.e. file.nunjucks, file.nunjucks.html, or file.njs etc.
I know that when working with other template languages it's common to use their name as the extension such as file.liquid, file.ejs, etc, but I've not seen much in reference to Nunjucks.
I personally prefer the extension '.njk', its also something that they have as an example on the Nunjucks docs.
File Extensions
Although you are free to use any file extension you wish for your Nunjucks template files, the Nunjucks community has adopted .njk.
If you are developing tools or editor syntax helpers for Nunjucks, please include recognition of the .njk extension.
Jon Buckley's nunjucks plugin for
wintersmith supports template naming convention
*.html
*.nunjucks
See https://github.com/jbuck/wintersmith-nunjucks/issues/8 for proof
So this naming convention is common everywhere wintersmith site generator is used. Especially the *.html seems to be fairly common also elsewhere.
Nunjucks's own documentation uses the *.html in examples of using {% include ..%} and {% extends ..%} tags and it says
...overview of the templating features available in nunjucks. Nunjucks is essentially a port of jinja2, so you can read their docs if you find anything lacking here...
and jinja's own documentation in turn says
...A template is simply a text file. It can generate any text-based format (HTML, XML, CSV, LaTeX, etc.). It doesn’t have a specific extension, .html or .xml are just fine...
My in-house site generator applies the nunjucks preprocessor also to files with extensions: *.md, *.markdown, *.htm, *.html, *.php, *.css, *.js, .htaccess but it can not be considered "common convention".
It might be possible to find out nunjuck's usage statistics and examples of used naming conventions using Google or GitHub or Wolfram Alpha computational knowledge engine or IBM Watson Analytics service...
I think that you can use any naming convention as long as you are able to refactor (rename) it anytime later
I have been experimenting with generating DocBook output using Maven running within Eclipse. I found the Maven plugin called docbkx, and it almost gets me there.
In the DocBook world, the way that you change some of the default behavior of the XSL transformations is by defining your own XSL file as a "customization layer." This file imports the standard XSL file and then any templates, etc. that you want to change are put in this file. Thereby, they are parsed after the standard templates, and your altered version is what is used.
To make this happen using the docbkx plugin, you have to tell it that you are using a custom XSL file in the configuration, with lines like
<foCustomization>src/docbkx/xsl/custom_print.xsl</foCustomization>
Then, in the custom XSL file, instead of needing to specify the location of the standard XSL file in the import statement at the top, you put in a symbolic path that the plug-in resolves:
<xsl:import href="urn:docbkx:stylesheet"/>
This all works very well. But I have been banging my head against the wall trying to understand how the plugin can be told to look for other things you might want to import. Two examples:
my customization layers import not just the regular stylesheet, but
also a custom titlepages XSL file I generated by the usual process.
I have a template to write a chunk of additional code into the HTML
output's head element. Specifically, it's the code to hook up to
Google Analytics. The code is in an external file.
In both cases the files being imported are sitting in the same directory as the customization layer, but best as I can tell the plugin can't find them. I don't know how to get the plugin to include these as it does its work.
Any ideas?
Thanks!
Alan
If you have something like:
src
|
+--docbkx
|
+--xsl
|
+--custom_print.xsl
+--custom_titlepages.xsl
and a pom like:
...
<plugin>
<groupId>com.agilejava.docbkx</groupId>
<artifactId>docbkx-maven-plugin</artifactId>
...
<foCustomization>src/docbkx/xsl/custom_print.xsl</foCustomization>
...
include in your custom_print.xsl the custom_titlepages.xsl:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
version="1.0">
<xsl:import href="urn:docbkx:stylesheet"/>
<xsl:include href="custom_titlepages.xsl"/>
You might find enlightening these documents:
Advanced Customization
Customizing both HTML and FO