In the context of setting up a homepage using Quarto, I am failing to find facilities and/or experiences doing so with multiple natural target languages.
I'm trying to achieve two versions of the same content (in my case one in English, one in German) within an identical navigational structure and a language name link to switch between them ...
Is this beyond the scope of Quarto? If not: how might this be achieved?
Thanks for any pointers.
Newer version of Quarto 1.2 available as pre-release (as of 09/2022) has a feature that should allow this more easily
https://quarto.org/docs/projects/profiles.html#language-content
This is the feature to use when looking to create a multi language book
Download for pre release can be done here: https://quarto.org/docs/download/
Related
My question is not about best practices for REST API URI design.
I've decided for myself, that i'm going to use the following approach:
https://theserver.com/api/v1/whatsoever
I'm much more curious about how to design the actual sourcecode in advance to easily extend the API with more versions.
Let's assume we've used a classic MVC-Framework for your favorite programming language. Our API works fine but we want to add & change functionality that is not backwards compatible. We did think about a nice URI design, but didn't think how our code should look in order to work nicely with different API versions. Crap.. What now?
Question: How should the source code for a versionable REST API look like?
Nice to have:
Not mixing up the different versions
Still best use of DRY
Don't reinvent the wheel over again
will be extended
Possible answers i can think of:
Same project - different Namespaces & Subfolders
Namespace: namespace App\Http\Controllers\v1\Users;
Folder: {root_folder}\app\Http\Controllers\v1\Users\UserLoginController.php
Different projects
Point https://theserver.com/api/v1/whatsoever to project 1
and https://theserver.com/api/v2/whatsoever to project 2
Here is my logic: - First of all we need to answer to the question "Why we need versioning?"
- If we can extend our API in way it is backward compatible, in that case we don't need versioning (All applications and services are going to use the same API and no changes are needed).
- If we can not can not provide backward compatible API in that case we need to introduce next version of our API. This will allow all applications and services to migrate smoothly to new version while to old one is working. After a time period (one year), first version can be obsoleted and stopped.
So based on the answer above I would keep API versions in separate branches in my repository. One codebase, multiple branches for each version. First branch corresponds to v1 which is stable and receives only fixes. No active development here. Second branch corresponds to v2 which has all new features.
Currently Java Lucene has feature called “More Like This”, which is used to find representative terms of a document which can be further searched to find similar documents.
I looked in latest CLucene code, but could not find this functionality.
Is it there in CLucene or something related to it? If not then are there any plans to include it?
If someone has done some work on this or area similar to this on CLucene, It will be great to hear from them.
I guess CLucene is just dead.
Currently you can get CLucene in two flavors - one is the 0.9.21
release, which has been proven to be stable over time, but is only
compatible with Java Lucene 1.9.1. Another option is our current
working copy on git, which conforms with Java Lucene 2.3.2
And according to this quote from sourceforge - you will never get MoreLikeThis feature, cause port of Lucene 1.x or 2.x is just too old.
Code: http://sourceforge.net/p/clucene/code/ci/master/tree/ (look at the commit date)
As you may have noticed, the wiki module has been dropped in v7 of OpenERP.
The question is: what alternatives are there it? Is there any community module available or in the works, providing wiki (or even markdown) documents?
For what it's worth, here's a little more info regarding what I said in comments.
In OpenERP 7.0, the wiki module has been renamed/revamped into the document_page module. You may find this mentioned in the last section (8.3 Renamed Modules) of the OpenERP 7.0 Release Notes. It now uses a simple WYSIWYG/HTML editor and stores the pages as HTML, instead of the previous wiki/markdown-based syntax. Therefore you may or may not see it as a true "wiki alternative". The goal is to make it easier and more flexible to use, effectively providing a minimalist CMS system inside OpenERP: you can use it to add static pages in your regular OpenERP menu (or your OpenERP portal), organize them in section/categories, etc., using freely editable HTML (you can edit the HTML source if needed), while preserving their
Note that several issues in the initial 7.0 release might temporarily make the document pages less user-friendly than they should: the WYSIWYG editor was not enabled in all cases in edit mode (fixed now) and the editor is sometimes too narrow (should be fixed soon).
On a related topic, it may also be interesting to know that OpenERP 7.0 provides a collaborative writing solution via the new pad module, allowing you to embed etherpad-lite pads in your documents. It's integrated with the project and the note modules, and you can use it easily for your own custom modules as well.
The OpenERP Knowledge Addons features a module to support MediaWiki syntax (currently only available/verified for v6.1).
We have a small website which was developed with the default language ('en'), without paying mind to the language or versioning capabilities of sitecore (ouch!). We simply forgot to set the correct default language at the start of the project.
Now we have an entire content tree of 'en' items, when they should be 'nl-NL' (it's a Dutch site). And I am wondering if there is an easy way of changing the language for all items in that tree (that does not involve hacking).
I found this Q&A, but it just talks about setting the default language. I'd like to do that, yes, but I would also like to set the correct language for the existing item(versions).
thoughts?
From what I remember we had a similar problem before. Not with filling a website in the wrong language, but having empty content that should be filled with default english content after creating the new language. What we did was export the language. In your case you could export the English language, create a dutch language and replace all entries in the English XML file that comes out with nl-NL values.
After you've done that you could import the language file as the Dutch language and all items are filled.
To me this sounds as the easiest and quickest approach, since you only have to search and replace some xml tags.
Good luck!
You could write a .NET program that would go through your whole content tree and update language parameter of each item accordingly. Sitecore APIs give you access to almost everything you see in the backend (including content manipulation) so it shouldn't be much of a problem to automate this task.
As an anternative you could copy your whole content from one language to another and then remove the language you don't want. Here's how to do it.
I'll caveat that my experience with it is limited, but from what I've seen, the Sitecore Rocks plugin for Visual Studio might allow you to script this.
http://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b
I am new to Redmine and I'd like to see if there is a good way to relate requirements (as stated by a product manager) to issues in Redmine. To me it seems that a low impact way to do it would be to define a requirement tracker and then add a custom field with a list of links to feature tickets.
I have tried doing this but cannot figure out how to add a link within a custom field text box.
So I guess I have a general question and a specific question,
General) Is there a recognised recipe in the Redmine community to achieve a linkage from a requirement to a list of features or issues?
Specific) Can I create a link to another issue within an issue field?
I think the answer to both questions is to use the built-in mechanism to link issues - it's called related issues.
Once an issue is created, you can add link to an other issue and indicate the type of relation (related to, blocks, precedes, etc.)
To separate requirements and features by means of a different tracker seems good to me, expecially if you'd like to apply different permissions or workflows.
See also the redmine manual about related issues, and an example of an issue with related issues http://www.redmine.org/issues/337
EDIT: More recently, subtasks have been added to redmine. They may be interesting to use in a scenario where a feature (issue) is implemented by means of different steps (=subtasks, like designing, programming, documentation,...) and/or by different persons (for example designer, programmer, ...).