Please note: This Blog was updated with a few clarifications on October 21st 2011.

As we announced in the release Blog for SQLyog version 9.3 we here publish instructions and tools for localizing SQLyog.

To understand how localization works you should first open the SQLyog 9.3 installation folder on your system. Inside it there is a (SQLite) database file named “L10n.db”. It contains all strings in all localizations distributed by us (currently English and Japanese) displayed by SQLyog GUI. If you have selected to run SQLyog in a non-English language SQLyog will load the localized strings from this file and use them for display and not the English strings.  To enable more languages just copy an updated “L10n.db” file with support for more languages into the SQLyog installation folder.  

The tools for localization are available from the SQLyog Community repository at Googlecode (http://code.google.com/p/sqlyog/). It is the contents of the ‘localization’ folder in the ‘source’ tab. From here on we will use the term SQLyog localization kit for the contents of this ../localization/ folder. To check out the localization kit for the latest SQLyog GA release use the link https://sqlyog.googlecode.com/svn/branches/stable_ga/localization/(and https://sqlyog.googlecode.com/svn/trunk/localization/ for the latest public release whether beta, RC or GA) for your SVN client (TortoiseSVN recommended for most Windows users). It contains tools and resources needed to add more languages/localizations to the “L10n.db” file.

Let us start listing the content:

* In the ‘bin’ folder you will find a “L10n.db” database completely identical to the one shipped with the SQLyog installer.

* In the ‘Strings’ folder you will find a XML-file named “Config.XML” and (in a recursive “String” folder) a folder for each language supported (named “en” and “ja”). In each of those folders you will find a number of XML files (following ‘Android XML’ specification) with English and localized Japanese strings respectively.

* The batch file ‘compile.bat’.  It is a batch script calling a ‘compiler’ that generates an updated “L10n.db file” based on the content of the “Strings” folder.

* The ‘Tools’ folder is not something you should normally care about. It contains some resources, shared libraries and executables etc. (such as the ‘compiler’ referred to above).  The content of it is used by the ‘compile.bat’ file – and not by user/translator directly.  

To make a translation there are bascially 4 steps:

1)

First step is to define a new language in the “Config.XML” file. We will assume that we are translating to German. In the passage that looks like

<language>
<ja langname=”日本語” />
</language>

.. add support for German like this:

<language>
<ja langname=”日本語” />
<de langname=”Deutsch” />
</language>

“de” is the language code and “Deutsch” is how it will display in the SQLyog UI. Please note that we use the language codes from this Microsoft document. It does not matter currently actually, but it may later be used for auto-detection of some LOCALE-specific parameters (decimal format, date format etc.), so please stick to the Microsoft recommendation unless there is a compelling reason not to do so. Also be careful not to change the encoding of the file. It is UTF8 and should remain so.

2)

Make a copy of the “en” folder and rename the copy “de”.

3)

Now comes the hard work. Translate the XML files in the “de” folder from English to German. And again be careful not to change the encoding of the files.

Also note the details:

* XML standards for encoding of special characters must be honoured (‘&apos;’ for “‘” (apostrophe) etc.). The characters that should be encoded are  & (&amp;), < (&lt;), > (&gt;) , ” (&quot;) and ‘ (&apos;) – and NO MORE! This is XML and not HTML!

* occurrences of “%d” and “%s” must be kept as they are and should be in the same order they appear in “en”. Failure to do so will result in an error in the next step.

* Also keyboard shortcuts are handled from the XML files. Actually there are two kinds of keyboard shortcuts in SQLyog (like in most Windows programs):

a) One kind is ‘static shortcuts’.

Those are the ones the you find listed in the “help .. keyboard shortcuts’ menu. Let’s have a look at a randomly picked string in English here:

<string name=”1027″>Schema Synchronization Tool (Ctrl+Q)</string>

The substring “(Ctrl+Q)” should not be translated. This kind of keyboard shortcuts are not localized. “(Ctrl+Q)” is just part of what is displayed. It is a constant string. The functionality of this type of shortcut is hardcoded into SQLyog.

b) ‘language dependent shortcuts’.

This is a Windows feature that it seems a lot of people don’t really know about. To understand what it is (if you don’t) just open SQLyog (in English) and press the ALT key. You will see that some letters in the menu become underlined.  For instance in the menu item “Table”, the “a” is underlined. You may next open the table menu by pressing “a” and even continue selecting from the submenu pressing a single letter key. In Windows this is achieved by preceeding “a” with an “&” in the menu (where it is not displayed – it only ‘codes’ the “a” to be a shortcut). So Windows ‘knows’ this menu item as “T&able” internally. That string is also what the “L10n.db” database contains.  Do not forget here that in the XML files “&” needs to be encoded as “&amp;”. So the German string in the XML file for the “Table” menu item could be “T&amp;abelle” (if you want to keep “a” as the ALT-keyboard shortcut in German). When choosing this type of shortcuts you should be careful not to use the same more than once in same menu level and you should of course try to follow de-facto standards as used in localized Windows itself, utilities that ship with Windows (Notepad etc.) as well as commonly used Windows programs (like office suites, browsers etc.).

Also you may use XML/HTML-comments in the XML-files.  That could be useful for instance if more people share the work of a translation or if there is something that you want to identify easily later.

A concluding comment on editors: Some editors may have issues with UTF8 and they should not be used. Notepad will work fine but it does not support syntax highlighting, auto-indenting and similar ‘developer features’ that are convenient to have. We have checked with Notepad++ that works fine – but there are undoubtedly dozens of editors available out there that will do the job. And also do not use a Word Processor – it should be a plain text editor.

4)

Once you have completed the translation of the XML files just execute the ‘compile.bat’ file from command line. German strings from the XML files you translated will be inserted to the ‘L10n.db’ database in the ‘bin’ folder. The updated ‘L10n.db’ can now be copied into the SQLyog installation folder and SQLyog will have the option for German language.  

Finally please note that we have a category in our Forums dedicated to localization.  If you are facing a problem feel free to discuss with us or fellow countrymen for details of a translation.

Comments(0)

“Publishing software in English will make you reach most of the global audience” is a myth. Users like software in their own language. For Non-English speaking audience localized software is a necessity. We heard it. SQLyog is now available in Japanese & will be made available in other international languages soon. We are using crowd-sourced human translation services from myGengo for translating SQLyog. I’d also like to add that our website is machine translated using Google Translate.

Embedded below are some related screenshots:

Option to change language

SQLyog in Japanese

If you want to do your own translation, we will soon provide instructions and tools for creating localizations as a ‘drop-in’ solution to an already installed instance. Watch this space for a post on it.

We are very excited about this new 9.3 release and would love to have your feedback. What other languages would you like SQLyog in?

Regards,
Chirag
Team SQLyog

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(5)

We have released SQLyog 9.2 GA with enhancements to the Data Search feature (and more).

Since we introduced the Data Search feature in SQLyog 9.1 we had a lot of positive responses – but also a few critical remarks that using the feature could cause unnecessary server load as well as unnecessarily long response times. Such scenario could arise when searching for a string in a BLOB column used for storing media files for instance. Or when searching all tables of a database when there was only need to search a few tables.

We have addressed this concern by adding filter options that let the user restrict the search to specific data types and to a subset of databases of a server, a subset of tables of a database or a subset of columns of a table.

Also we have added “+” and “-” operators for inclusive and exclusive exact match.

I would like to elaborate a little more on Data Search:

Data Search does not replace SQL, of course. It is a supplementing feature. It is in particular useful when your are searching for something you don’t know what exactly is and don’t know exactly where to find. And when you are just too lazy to write a long SQL statement. As we have posted here before you could consider the Data Search feature as a tool to ‘google your database’ (as google ‘advanced search’ operators are used). But a database has a hierachy and has datatypes what a document has not. So this filtering option is a logical database-related enhancement to the google ‘advanced search’ syntax used for documents.

Let us take an example: Suppose you want to find all instances of email addresses with a specific domain name in all your networked systems (on the Internet as well as Intranet). We have 3 such public systems (our Forums, Blog and FAQ) for our MySQL-related products alone  that are ‘standard applications’ that we did not code ourselves and thus do not know internals about very well. In all those systems people may comment or contact us. Add to this our non-public systems – like our CRM system and our support ticket system (based on our own web application IssueBurner that aggregates everything sent from and received to our contact email addresses to a database). As all the mentioned systems use a MySQL backend we will now easily be able to answer the question “Who have ever contacted us with a @like.this email address, when did it happen and what was the subject/matter?”. Simply because we can find the data in all systems. And anybody in our organization can do (provided that they have access) without knowing details about how and where the different applications store the information.

When we introduced Data Search in 9.1 I actually expected some comments that “this is a feature for amateurs and I do not intend to use it as I am familiar with SQL”. We did not get such comments till now! I think users already found out that it saves a lot of time.

Also in this release we are following up on the ‘Foreign Key lookup’ introduced in 9.0. This is now also functional from the RESULT tab in SQLyog.

And finally In this realease we added a ‘date picker’ GUI for managing DATE, DATETIME and TIMESTAMP columns as well as an option to clone a connection. Both were popular user requests for some time and have now been implemented.

See all details for this and other recent releases here.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(1)

Changes (as compared to beta 1) include:

Features:
* Added a filtering option in Data Search. You may select to search specific data types only and/or a subset of databases in a connection, a subset of tables in a database or a subset of columns in a table.

Bug fixes:
* ALTER VIEW could fail to open the view definition in MySQL 5.1+ if an underlying table was ALTERed after creation of the VIEW. This is a server bug due to which SHOW CREATE TABLE failed. SQLyog now works around this bug by fetching the VIEW definition from information_schema if SHOW CREATE TABLE fails. One limitation of this is that the ALGORITHM clause will not necessarily be the exact one specified while creating the view as Information_Schema has no record of the ALGORITHM clause.
* Execute SQL Script will now show data transfered in percentage rather than the size. Once the execution/import is succesfull it will show the total size.
* Removed extra whitespace in query when displayed in the message tab due to an error.
* The execution time displayed for a query is now formatted for better readability.
* SJA could fail to send mails when using a SMTP server on localhost.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(0)

Changes (as compared to 9.1) include:

Features:
* The ‘Foreign Key lookup’ introduced in 9.0 is now also available in RESULT tab. With HTTP-tunnel this is not possible however.
* Added a calender control for managing DATE, DATETIME and TIMESTAMP columns.
* Data Search enhancements: 1) Added an option to search on column level. 2) Added Google-style “+” and “-” operators meaning ‘exact match’ and ‘not matching’. ‘+’ and -’ may be combined with “double quotes” and the NULL keyword. 3) Added an option to use hexadecimal patterns for search using x’..’ notation (note that this feature requires MySQL 4.1 or higher).
* Added an option to clone a connection in the connection manager.

Bug fixes:
* With multiple connections open simultaneously the active connection could display a warning that data were not saved belonging to another connection.
* On Windows Vista and higher CSV-import of numerical data written in ‘scientific notation’ failed.
* Fixed a crash with ‘stored programs’ if the ‘stored program’ definition was loaded from a file with a long name (too long to display fully in the tabbed interface).  This bug was introduced in 9.1

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(0)

MySQL Data Search

Comments(15)

Changes (as compared to 9.02) include:

Features:
* Data Search (that was introduced in 9.0 beta but removed in 9.0 GA) is back. We have added an option to search on global/server level and an option to use regular expressions for search.
* Quite a lot of dialogs have been made resizable. This includes ‘Reorder Columns’, ‘Copy Table’, ‘Add Favorites’, ‘Organize Favorites’, ‘Export as SQL Dump’, ‘Export As (CSV/html/…)’, ‘Table Diagnostics’ and ‘Copy Database’. Those left that are not resizable now are either those where it would not make sense and some that will very soon be replaced with another interface.
* Redesigned the ‘advanced’ option in Import External Data tool.

Bug fixes:
* The ‘Job manager’ could fail to add jobs from the SJA wizards. This bug was introduced in 8.8.
* Import External Data  could fail to display all columns of target table when importing from a source containing lesser columns than target.
* In TEXT mode the last row of data could fail to display if it contained a NULL value.
* Export (to various formats) could cause SQLyog to ‘hang’ with tables with 500+ columns.
* In ‘export as Excel XML’ it was possible to enter alphabetics for numerical parameters and the result of the export was unpredictable.
* In ‘Import External Data .. advanced’ the complete job would abort even if user had only specified an abort condition for a single table. Also when the table was not present in the target and abort option was selected only the table structure was created and no data were imported. These bugs were introduced in 9.0.
* In ‘edit’ menu the shortcut to ‘execute query’ was always displayed as F5 irrespective of user setting.  This is a regression introduced in 9.0.

Miscellaneous:
* When opening SQLyog will now only display a Query tab (and no Query Builder or Schema Designer tab as before).

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(1)

Changes (as compared to 9.01) include:

Bug fixes:
* The option in ‘preferences’ to ‘Keep focus on SQL editor after query execution’ did not have any effect. This bug was introduced in 9.0.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(0)

Changes (as compared to 9.0) include:

Bug fixes:
* Introduction of the option to TRUNCATE TABLE in the ‘Import External Data Tool’ introduced a bug. If user selected DROP+ (RE)CREATE TABLE only structure would be created but data would not be imported.

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(1)

This is the first GA release in a new major branch of the SQLyog MySQL GUI.

This release introduces an easy way to look up proper values for values inserted to columns that have a Foreign Key CONSTRAINT.  Foreign Key CONSTRAINTs can be difficult to handle for a human user because when updating a ‘child’ table valid values for columns that have such CONSTRAINTs  in the  ‘child’ table will often be ‘just a code’ ( an autoincrement integer or some very ‘compressed’ and ‘symbolic’ values (like item numbers, order numbers etc.).

This SQLyog release provides a direct way to look up in ‘parent’ what should be inserted in child. It works like this: In both GRID and FORM mode a ‘…’ symbol will display if the actual column has a Foreign key CONSTRAINT. If you enter some value in the cell and next click this button SQLyog will find all matches for what you have entered in the ‘parent’ table. It does so in two steps:

1) First it will try to find an exact match (using ” = ” operator) in the ‘parent’ column of the ‘parent’ table. So if you are able to memorize, the full matching row from ‘parent’ will display and you can verify with a single click.

2) If no match is found in first step it will try to find a ‘fuzzy’ match (using ” LIKE ” operator with wildcards attached to the string before and after) against all columns of the ‘parent’ table.

A new dialog with the result of this search is displayed. Once the search results display you can select any matching row found in ‘parent’ table and SQLyog will take care that a correct and valid value is inserted to the ‘child table’. If the first search returns too much ‘noise’ you may search again specifying customizable filters.

Note that the search string will not need to be a valid value for the ‘child’ column as it is not saved.  It is used for searching in the ‘parent’ table . Even the (rare) situation where a ‘child’ colum has more than one ‘parent’  is handled.

Other changes (as compared to 8.82 ) include:

Registration:
* Please note that this release requires a new registration code as compared to previous 8.x versions.  Before installing please ensure that you have the registration details available.  Existing customers may retrieve the details from our Customer Portal.

Features:
* In CSV-exports NULL-values can be written as a user-specified string. ‘\N’ is default for compliance with MySQL (SELECT INTO OUTFILE and LOAD DATA), but for use with other programs (such as spreadsheets) other options may be relevant.
* Added an option to automatically add ‘child’ tables to selected tables (before it was only possible to add ‘parent’ tables) in Schema Designer and Query Builder.
* Added a “Change Background Color” option in Edit menu
* A foreground color for text display contrasting a defined background color is now automatically provided by SQLyog in Object Browser and Connection tab.
* The visual effects of tabs have been improved with continued scrolling support. There is a + icon next to the last tab which provides options to add new tabs.
* In ‘Import External Data’ there now is an option to TRUNCATE target tables. Before only DROP+CREATE was possible.
* In ‘Import External Data’ added an option to discard/clear column DEFAULTs. Some ODBC-sources use default specification that will not work with MySQL and it was tedious to define this for every table when a large number of tables were imported.

Bug fixes:
* Data entered from the GUI to mange ENUM/SET types were not escaped properly what caused problems with the ” ‘ ” (single quote) and ” \ ” (backslash) character.
* Focus in Object Browser was lost when creating a Stored Procedure.
* There is now a button/link to open the log file in each dialog wherever it is referred.
* Fixed an issue where non-binary data were displayed as “(Binary/Image)”.
* Now TAB/SHIFT+TAB keys will rotate through buttons, check-boxes and tools in Result/Table Data tabs.
* Fixed a crash occurring when running Schema Sync and a Query Builder or Schema Designer TAB was active in the program main window.
* Fixed a truncation issue while importing binary data from PrimeBase server.
* When repeatedly stepping forward and backwards in SJA wizards most recent data entered by user could be lost and replaced with previous values.
* Deleting multiple rows af a table without a Primary Key in one operation could crash SQLyog. This bug was introduced in 8.8.
* Fixed a crash occurring when connecting on some Windows 7 systems with Service Pack 1 installed.
* While formatting multiple queries the SQL formatter now does not add a new line if a new line already exists between two queries. Formatting multiple times would insert new empty lines between queries for each cycle.
* A few more Query Formatter ‘refinements’.
* When closing a Query tab or a Query Builder Tab user was promted to save even if he/she had ‘blanked’ the content of the tab. Now it does not unless the tab was populated from a file. SQLyog will still prompt user to save in this case.
* A small GUI fix with the ENUM/SET dialog.
* After dropping a column from Object Browser context menu focus in Object browser would change randomly. Now focus will be retained on the parent COLUMNS folder.
* SQLyog could crash when attempting to delete rows from the table having a foreign key constraint. This bug was introduced in 8.82 due to improvements made in scrolling.
* SQLyog could crash while the table contents were being loaded in table data tab and the user tried altering the table at the same time.
* If server had timed out the connection SQLyog could fail to reconnect when opening a ‘stored program’ definition

Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

Comments(1)