I am trying to figure a way to use already translated .md files (Russian Language) with Sphinx. I use readthedocs.io and I have already read the process of making translatable files (.po/.pot) from:
(1) https://docs.readthedocs.io/en/latest/localization.html
(2) https://docs.readthedocs.io/en/latest/guides/manage-translations.html.
This process requires to make .po or .pot files, translate them, and then produce translated html files - served under https://project.readthedocs.io/$language/$version
What I want is to use a different directory (for example named ru) and place there the Russian .md files.
Is that possible? How is it possible to avoid creating these .po/.pot files?
Related
I want to have a base64 encode a .mo file and use it as the translation file for wxPython. Since it will be located in a .py file.
I have a wxPython project that is getting compiled a couple different ways. Icons are no trouble because they are packed in a .py file and base64. Translations in .mo files are a pain in the butt. Is it possible to do this same cheat for the translations? Include them not in a correct .mo file, but just dump the translation in base64, or gzipped base64?
wx.FileTranslationLoader() seems to be the only wx.TranslationLoader() that exists. It says I can replace that translation loader and use my own. https://wxpython.org/Phoenix/docs/html/wx.Translations.html#wx.Translations.SetLoader However to do that I need to return an msgCatalog which isn't apparently an object type that I can find anywhere.
This seems like a solid method of faking this so builders that pack all my .py will be set for their translation files but it doesn't seem easily doable but maybe there's an easy hack I'm missing. Maybe ducktype the MsgCatalog but I dunno what methods it needs to have. And I don't actually want to read the .mo myself, just give it a bytestream like object. In theory I could write the mo a locale directory but usually the internal fileystems of various installs are fake so I'd end up writing some weird files to disk. I suppose I could do that in the temp directory but that seems extra hacky.
Are there any rules for file extensions? For example, I wrote some code which reads and writes a byte pattern that is only understood by that specific programm. I'm assuming my anti virus programm won't be too happy if I give it the name "pleasetrustme.exe"... Is it gerally allowed to use those extensions? And what about the lesser known ones, like ".arw"?
You can use any file extension you want (or none at all). Using standard extensions that reflect the actual type of the file just makes things more convenient. On Windows, file extensions control stuff like how the files are displayed in Windows Explorer and what happens when you double click on it.
I wrote some code which reads and writes a byte pattern that is only
understood by that specific programm.
A file extension is only an indication of what type of data will be inside, never a guarantee that certain data formatted in a specific way will be inside the file.
For your own specific data structure it is of course always best to choose an extension that is not already in use for other file formats (or use a general extension like .dat or .bin maybe). This also has the advantage of being able to use an own icon without it being overwritten by other software using the same extension - or the other way around.
But maybe even more important when creating a custom (binary?) file format, is to provide a magic number as the first bytes of that file, maybe followed by a file header structure containing a version number etc. That way your own software can first check the header data to make sure it's the right type and version (for example: anyone could rename any file type to your extension, so your program needs to have a way to do some checks inside the file before reading the remaining data).
I am rebuilding a site with docpad and it's very liberating to form a folders structure that makes sense with my workflow of content-creation, but I'm running into a problem with docpad's hard-division of content-to-be-rendered vs 'static'-content.
Docpad recommends that you put things like images in /files instead of /documents, and the documentation makes it sound as if otherwise there will be some processing overhead incurred.
First, I'd like an explanation if anyone has it of why a file with a
single extension (therefore no rendering) and no YAML front-matter,
such as a .jpg, would impact site-regeneration time when placed
within /documents.
Second, the real issue: is there a way, if it does indeed create a
performance hit, to mitigate it? For example, to specify an 'ignore'
list with regex, etc...
My use case
I would like to do this for posts and their associated images to make authoring a post more natural. I can easily see the images I have to work with and all the related files are in one place.
I also am doing this for an artwork I am displaying. In this case it's an even stronger use case, as the only data in my html.eco file is yaml front matter of various meta data, my layout automatically generates the gallery from all the attached images located in a folder of the same-name as the post. I can match the relative output path folder in my /files directory but it's error prone, because you're in one folder (src/files/artworks/) when creating the folder of images and another (src/documents/artworks/) when creating the html file -- typos are far more likely (as you can't ever see the folder and the html file side by side)...
Even without justifying a use case I can't see why docpad should be putting forth such a hard division. A performance consideration should not be passed on to the end user like that if it can be avoided in any way; since with docpad I am likely to be managing my blog through the file system I ought to have full control over that structure and certainly don't want my content divided up based on some framework limitation or performance concern instead of based on logical content divisions.
I think the key is the line about "metadata".Even though a file does NOT have a double extension, it can still have metadata at the top of the file which needs to be scanned and read. The double extension really just tells docpad to convert the file from one format and output it as another. If I create a straight html file in the document folder I can still include the metadata header in the form:
---
tags: ['tag1','tag2','tag3']
title: 'Some title'
---
When the file is copied to the out directory, this metadata will be removed. If I do the same thing to a html file in the files directory, the file will be copied to the out directory with the metadata header intact. So, the answer to your question is that even though your file has a single extension and is not "rendered" as such, it still needs to be opened and processed.
The point you make, however, is a good one. Keeping images and documents together. I can see a good argument for excluding certain file extensions (like image files) from being processed. Or perhaps, only including certain file extensions.
I'm developing a plugin in Jekyll that inserts a new Liquid Tag (a block tag) named latex. It's purpose is to insert a block of LaTeX source code inside a post source file this way:
... post file contents ...
{% latex density=300 usepackages=pstricks-all, %}
\pspicture(5,5)
\psframe(0,0)(5,5) \psline(0,0)(5,5) \psline(0,5)(5,0)
\endpspicture
{% endlatex %}
... post file contents ...
The output post will contain a <img> tag instead of the Liquid Tag block once compiled and the LaTeX source will be compiled by a chained execution of latex, dvips, convert. So it will depend on external programs (TexLive and ImageMagick).
I've not found any issue with the explained so far. I can take the block of LaTeX, put it in a temporary file, and finally compile it to PNG. The rendered files must be put in the same folder of the post.
But just there I'm stuck: I want to put the generated PNG image to this folder inside the destination output folder. No problem defining a site-config variable to define the folder (in fact, I do that), nor put a file there. The problem is simple: I can write to the source folder, but the generated files will not be copied to the destination folder.
I know the reason: Jekyll generates first and renders afterwards. The copy process happens before the render part, so the generated files will not be copied.
I've found this SO entry: "How to generate files from Liquid blocks in Jekyll?", but the answer doesn't feel right: You must make a two-pass build for the files to be copied.
Also found "Generate file inside _site with Jekyll plugin", but this is not applicable because I don't want to render documents by templates.
The solution I've been planning is this:
Keep a folder with all the generated files and some index strategy for their final placement.
Implement a Sitewide method for the final placement procedure, something like:
class Site
def generate_latex_adds
// Code that copies the generated files to destination folders
end
end
Add self.generate_latex_adds calling that method inside the site_process.rb script just before the self.cleanup and self.write calls.
This will probably solve the problem, but I feel wrong to modify the site_process.rb. I'm considering pull this Liquid Tag to the community as a GitHub project, and as such, I must document this manual edit of site_process.rb to the users of this plugin. I know it's probably a common situation and a common solution, but I wonder if there is a better way to pospone the copy of the generated files without modifying core files. I'd like to keep the plugin simple: just copy the plugin file to the _plugins directory.
Any ideas?
EDIT: I'm more interested in the reasoning that on the actual code. I want to learn, not asking for a code solution.
As anyone has answered my question up to now, and I had kept investigating the issue. Finally I've got an elegant solution: use the Jekyll::StaticFile class. I have missed that class (sidenote: Read more carefully the docs).
When you add one object of this class to the site.static_files array, you are marking this file as pending for copy after the render process is completed. In fact, the copy of such files is done in the site.write process. Take a look at the site_process.rb file in your Jekyll installation.
The usage of this class is easy. When you need to mark a file for future copy, you simply execute a code like this:
site.static_files << Jekyll::StaticFile.new(site, site.source, path, filename)
Where path and filename depends on the location of your file in the src folder.
And that's all: You generate the files in the src folder, mark them as pending for copy and let Jekyll do the rest. No modification of site_process.rb at all!
You can take a look at the resulting LaTeX -> PNG liquid tag code at GitHub: https://github.com/fgalindo/jekyll-liquid-latex-plugin
I've also implemented a cleanup method there to eliminate orphaned generated files from posts that have been modified and rebuilt.
I have a website that runs off an OpenWRT router. I'd like to optimize the site by removing an files that aren't being used. Here is my directory structure...
/www/images
/www/js
/www/styles
/www/otherSubDirectories <--- not really named that
I'm mostly concerned about identifying images that are not used because those take the most space. But it would also be nice to identify style sheets and javascript files that are not being used. So, is there a way I can search /www and all sub directories and files and print a list of files in /www/images, /www/js, and /www/styles that are not referenced by any other files?
When I'm looking for files that contain a specific string I use this:
find . | xargs grep -Hn 'myImage.jpg'
That would tell me all files that reference the image. Maybe some variation of that?
Any help would be appreciated!
EV
Swiss File Knife is very nice tool.
Find out which files are used (referenced) by other files through fuzzy content analysis
Consider using a cross-reference program (for example, lxr) for this problem. (I haven't verified if lxr can do the job, but believe it can.) If an off-the-shelf cross-reference program doesn't work, look for an open source cross-reference program in a language you know, and adapt it.