I found that there is no plugin for automatic language detection, how to add it?
Can this function be integrated into VuePress to automatically detect the client language and jump to the corresponding multilingual site.
There is an official plugin for it, it's just incredibly hidden and also took me quite some time to find:
https://vuepress.github.io/en/plugins/redirect/
Set "locales: true" and then make sure all files are placed in a language directory inside of the docs directory. So your docs/ directory should only contain .vuepress/ and then more folders for all languages with the same structure:
/docs/.vuepress/
/docs/en/
/docs/de/
/docs/pt/
/docs/zh/
[...]
Related
I am using a custom language (antha) which gets transpiled to go.
Antha script files end in .an and get transpiled to.go
I have a function in a .go file and I want to find its usages in .an files.
How do change the "find usage" feature of Gogland to include the .an files? Currently it only searches in the .go transpiled scripts.
A language plugin that understands antha would need to be created / installed in order for that feature to work, otherwise the IDE has no way to understand how to make that feature work. If you wish to learn about plugin development for IntelliJ Platform, you can start here.
I have searched for a solution for organizing Go files in a project and found this post. I wonder what the role of the cmd folder is, that was used in the 2nd section of that post. Is it a magic word for the Go compiler?
On the other hand I was reading the Go documentation and there is nothing about a cmd folder in there.
So what about this folder? And what is the best practice for structuring project files in Go that support source files, projects binaries, 3rd party packages and unit tests.
So what about this 'cmd' folder?
The post has already made it clear, to summarise:
It's not a magic nor standard in Go. It's just a convention.
You can have multiple binaries when putting them into a sub-folder which is not possible in the root folder.
By making you taking your binary as a client instead of a host or portal of your application, it can drives you to the so-called 'library-driven-development' way of architecting your program. This separation 'helps you make a cleaner abstraction' and more common of you code logic.
And what is the best practice for structuring project files in Go that support source files, projects binaries, 3rd party packages and unit tests.
I'm not sure about the best practice. The official documents have many hints about the project files structuring. On my personal practice, besides the cmd folder for the binaries, I
Group source files into packages(sub-folders) inside the src folder,
Copy 3rd party packages to the vendor folder;
Place unit tests files side by side with its target source file.
These links may be helpful:
Organizing Go code
The Go Blog: Organizing Go code
The Go Blog: Package names
golang-standards/project-layout (*)
As #DiegoMendes pointed out, there are controversy about proposals in the last link. You should also check the issue 117 of that repo which contains a lot of valuable information.
The author of the post you cite explicitly says the Camlistore application introduced him to the cmd convention.
If you look at the source code to Camlistore you will notice that project uses a custom system for building, namely "make.go".
cmd is special only because the Camlistore project uses "go run make.go" to build and make.go is aware of how to build targets in the cmd directory. Or in the more general case, cmd is special only if you use a build system that treats it as special.
My application is to be written using wxWidgets, but the question may be related to using gettext in general.
For the application named app, some sources suggest I sould create <lang>/ subdirectory, create the app.po file inside with the translation, and convert it to the distributed app.mo file in the subdir.
Another approach is to create app.pot (i.e. the template from the sources via xgettext), and to msginit and msgmerge it to the <lang>.po for the language.
For the first approach, more .mo files can be put inside the <lang>/ subdirectory. Also the wxLocale::AddCatalog() gets the domain name (where the domain can naturally be app, wxstd, etc.). On the other hand, the <lang>.po file name is descriptive on itself -- wherever it is located.
What are the pros and cons of the two approaches? Is there any text that explains the path to be chosen?
Thanks for your time and experience,
Petr
The Unix convention is to use app.mo for binary catalogs, see the contents of /usr/share/locale directory. Sometimes lang.po is however used for the source ones, as done in wxWidgets itself (see its locale subdirectory), but they're still installed into language-specific subdirectory using the app-dependent name.
The tutorial http://sinnerinc22.blogspot.de/2010/07/adding-syntax-highlighter-to-jamwiki.html describes how to enable syntax highlighting in JAMWiki.
My problem is that in the recent version of JAMWiki v1.2 the two files to be modified WEB-INF/jsp/top.jsp and WEB-INF/jsp/close-document.jsp do not exist any longer...
There is a third-party syntax highlighting tag extension available with JAMWiki 1.2 link that may work for you
I have added SHJS to my installation just following SHJS instructions rather than JAMWiki instructions. Simply edit JAMWiki JSP pages to add content as documented here. To see how does it work, look into the source code of this HTML document.
You even do not need to compile anything after you edit JSP, the server does this for you automatically.
Following up on Audrius's answer, here's exactly what you need to modify.
./jamwiki.war/WEB-INF/jsp/topic.jsp Modify it to look like this
Download the SHJS zip and copy all of the individual files from ./css/, ./lang/, ./sh_main.js, and ./sh_style.css from the zip to JamWiki.war/shjs/. (This will flatten the directory structure so everything is now in ./shjs/. Flattening the structure is optional but it makes for easier paths when referencing them in the jsp.)
You can modify the .war with 7zip or dig into your web app container file system and place the JSP and shjs folder directly.
Redeploy or refresh as needed depending on your preferred edit method.
I am using Xcode as part of my build for OS X, but since it is not the only IDE used, files may be added from the file system directly.
As far as I can tell, there are two ways of adding folders:
Folder reference picks up all the changes on the file system but does not register any of the files as sources.
Recursive copy allows for the files to be built but I need to constantly maintain the file structure
I am wondering if there was a way to setup Xcode to build all of the files that are a part of the folder reference or failing that, if there is a quick script to automagically fix file system discrepancies.
I came up with proof-of-concept solution that works, but will require some work to use in production. Basically, I set up a new "External Target", which compiles all source files in a given directory into a static library. Then the static library is linked into the Main Application.
In detail:
Create a directory (lets call it 'Code') inside your project directory and put some source code in it.
Create a Makefile in the Code directory to compile the source into a static library. Mine looks like this.*****
Create an External Target (lets call it 'ExternalCode') and point it to the Code directory where your source and Makefile reside.
Build the ExternalCode and create a reference to the compiled static library (ExternalCode.a) in the Products area of your project. Get Info on the reference and change the Path Type to "Relative to Built Product".
Make sure ExternalCode.a is in the "Link With Binary Libraries" section of your main target.
Add the ExternalCode target as a dependency of your main target
Add the Code directory to your "User Header Search Paths" of your main target.
Now when you drop some source files into 'Code', Xcode should recompile everything. I created a demo project as a proof of concept. To see it work in, copy B.h/m from the 'tmp' directory into the 'Codes' directory.
*Caveats: The Makefile I provided is oversimplified. If you want to use it in a real project, you'll need to spend some time getting all the build flags correct. You'll have to decide whether it's worth it to manually manage the build process instead of letting Xcode handle most of the details for you. And watch out for paths with whitespace in them; Make does not handle them very well.
Xcode's AppleScript dictionary has the nouns and verbs required to do these tasks. Assuming your other IDE's build scripts know what files are added/deleted, you could write very simple AppleScripts to act as the glue. For example a script could take a parameter specifying a file to add to the current open project in Xcode. Another script could take a parameter to remove a file from the current project. Then your other IDE could just call these scripts like any other command line tool in your build script.
I'm not aware of any built-in functionality to accomplish this. If you need it to be automatic, your best option may be to write a Folder Action AppleScript and attach it to your project folder.
In all likelihood it would be a rather difficult (and probably fairly brittle) solution, though.
It's not pretty, and I think it only solves half your problem but... If you recursively copy, then quit xcode. Then you delete the folders, and replace them with simlinks to the original folders, you at least have files that are seen as code, and they are in the same files as the other IDE is looking at... You still will need to manually add and remove files.
I sort of doubt that there's a better way to do this without some form of scripting (like folder actions) because xcode allows you to have multiple targets in one project, so it's not going to know that you want to automatically include all of the files in any particular target. So, you're going to have to manually add each file to the current target each time anyway...
One way to import another file from add/existing file:
and set your customization for new file that added .
see this