January 2015 - docs - lists.mariadb.org

[Maria-docs] Finding the right link to/from translated KB articles can be confusing
by Jean Weisbuch 20 Jan '15

20 Jan '15

I translated an article that is on this untranslated category (https://mariadb.com/kb/fr/mariadb/what-is-mariadb/) but i havent been able to use the usual ways to put links to other translated KB articles ("mariadb-vs-mysql-compatibility", "mariadb-vs-mysql-features" and "source-getting-the-mariadb-source-code") where the usual links of the form "fr/english-link" and "translated-link" doesnt works. I had to put the full URL (excluding "https://mariadb.com/kb/fr/") which are "mariadb/la-compatibilite-entre-mariadb-et-mysql", "mariadb/mariadb-vs-mysql-features/" and "mariadb/les-premiers-pas/obtenir-installer-et-actualiser-mariadb/comment-compiler-mariadb-a-partir-de-la-source/source-getting-the-mariadb-source-code/". What is the best practice here, i didnt find mentions about it on the documentation? Would it be possible to have by default links on translated articles to point to translated articles (when available) when the "default" URL (using the English KB page link without specifying the language) is used on the code ; having to check and fix almost every links when doing a translation is time consuming and could easily lead to mistakes. -- Another small issue : The documentation about translating KB pages (https://mariadb.com/kb/en/meta/translation-howto/) states that : "All translated articles must be placed in a translated category. If the translated parent does not exist, the article will be placed in the grandparent or root category. Please take the time to translate the parent category before translating any articles in that category.". But if i try to translate a category such as https://mariadb.com/kb/en/mariadb/faq/ i got an error message : "Sorry, you do not have permission to create an article here."

3 4

[Maria-docs] Having the possibility to have a per major release KB pages
by Jean Weisbuch 15 Jan '15

15 Jan '15

As 10.1 is on its way and has new features of its own and some others got deprecated, its getting a bit "complex" on some KB pages to have documentation for multiple major versions (eg. 5.1, 5.2, 5.3, 5.5, 10.0, 10.1, ...) on one page along with minor versions specifics (when changes got introduced after the first released version). A simple example (not the best one but its the page i was reading at the moment) : the SELECT statements documentation (https://mariadb.com/kb/en/mariadb/documentation/sql-structure-and-commands/…). The first part of the documentation is about the syntax but it only shows the 5.5 GA syntax, features added later must be found manually on the page and syntaxes deprecated after the 5.5 GA will have to be found manually too. It would be interesting to have the possibility to use a "generate per major release" flag on KB pages that would automatically generate subpages that are major-version specific with a switch between major release pages like on the MySQL documentation. For example, if a <<product mariadb from=10.0 to=10.0>> macro would be used (only using a major release version number or maybe by adding a "specific" flag to the macro to avoid mistakes), there would automatically be a 5.5 and a 10.0, 10.1 subpages (specified, previous and next releases) created where the content of the tag would only be shown on the 10.0 page (and on the "generic" page that shows every release infos such as its done at the moment). With that kind of automatic generation, it would be simpler to keep up to date documentation for every major release without having to create a specific page per major release or to display multiple <<product>> macros on one page while keeping it simple to manage (especially as there are also the translations to keep up). Having the possibility to set a from/to product version for a whole KB page could also be interesting to keep the browsing of the KB pages lighter if the user selected a specific MariaDB release, it could also be used to put automatically the info on top of the KB page in a clean way (example of how it is done actually : https://mariadb.com/kb/en/mariadb/documentation/managing-mariadb/optimizati…) and it could be of use for automatically generated documentation from the KB pages. These ideas are not perfect and i dont know if it would be simple to implement these on the KB code but the need for a solution for the problem will only keep growing.

2 1

[Maria-docs] suggestions on terminology
by Federico Razzoli 09 Jan '15

09 Jan '15

Hi! I think that we all agree that having a clear terminology is important, for example when explaining a problem or its possible solutions. However, there are at least 2 cases where I am not completely happy with the terminology used in MariaDB Docs. I will suggest some variations here - if a better solution is found, I will be happy to help editing the occurrences of those terms. * Virtual Columns The problem here is that VIRTUAL and PERSISTENT columns are both called virtual columns. Interestingly, one could say that virtual columns are a type of virtual columns :) Since VIRTUAL and PERSISTENT are keywords, the only solution is changing the general name. My suggestion is Calculated Columns (from SQL Server). * Dynamic Columns While this is a good term, there is not an "official" term to indicate the table column containing virtual columns. I suggest Dynamic Columns Set, or Container. * Procedure I never seen a "procedure" other than "procedure Analyze". But this feature exists, and its name is easely confused with Stored Procedures. I don't have a suggestion here (especially because PROCEDURE is a keyword). I hope that these suggestions will be useful. Regards, Federico

2 2

[Maria-docs] Usage of an informal tone on the documentation on the KB
by Jean Weisbuch 09 Jan '15

09 Jan '15

There are no details about what tone should be used on the KB pages (https://mariadb.com/kb/en/meta/contributing-to-the-mariadb-knowledge-base/) and many of the KB pages use an informal/personal tone with the use of the first (i, we) and second person (you) which i think doesn't suit very well for a enterprise-grade product documentation, at least it doesn't feels right when translating pages to French. Is that intentional or not and should there be a rule about that at least on documentation pages?

3 2