Past few years, I have been using a lot of C# and JavaScript. Writing backend code and API using ASP.NET Core and client applications using Angular. C#/.NET Core and JavaScript/TypeScript are great languages, but Delphi still has its place.
Soluling localization tool has four parts: the GUI tool, the command-line tool, browser app, and the cloud service. Delphi is used in GUI and command-line tools. The big difference between Soluling and other modern localization tools/services is that in Soluling, the file scanning, string extraction and localized files creating happens locally on the developer's machine or on the build server. As we know, three operating systems are used in the build process: Windows, Linux, and macOS. So we needed a programming language that can handle all these in the same code base. There are several possible choices here: Python, Java, JavaScript, .NET Core, and Delphi! Yes, the Delphi compiler can create native code from the same source code for Windows, Linux and Mac.
Traditionally Delphi has been a great tool to create Windows desktop applications. This is why it was a good choice to create Soluling's GUI tool. However, the command-line tool needs the same classes as the GUI minus the UI part. When we started the Soluling project, Delphi did not support Linux, only Windows, and macOS. We hoped that Linux support would come, and soon it did. We also considered Java and Python, but because for both of them, building GUI is so much harder than with Delphi, we chose Delphi.
Now when we are implementing the cloud version, we use C# and Delphi. All the normal backend code like API, DB access is done in C# ASP.NET Core, but the file scanning, string extraction and file building is using the same Delphi code as Soluling GUI and Soluling command line. The shared code size is huge. Because we support more than 100 file formats and database formats we have hundredths of classes totaling almost 700 000 lines of code. This is all none UI code. With desktop and web UI it is almost double. the only place where we do not use Delphi is the browser app where we use Angular.
Using Delphi, we can reuse the same code in three places: GUI, command line and cloud. Soluling's customers can use the Soluling command-line on Windows, Linux and Mac. The GUI version is still Windows only and probably will stay like that.
sunnuntai 21. kesäkuuta 2020
lauantai 20. kesäkuuta 2020
Soluling - a new localization tool
Last week Soluling was released. It is a new localization tool. You might ask why do we need another localization tool when we have so many existing. There are several traditional desktop localization tools such as SDL Passolo, Alchemy Catalyst, and Sisulizer. There are also several web-based tools, such as Memsource, Crowdin, and Phrase. Well, between these two groups is a gap that Soluling fits. The desktop-based tool has the possibility to read all files of the development environment. It is easy to create a new project and update it when needed. The drawback is the translator collaboration. You need to send the project file to a translator, and they have to use that specific tool to edit it. An alternative approach is to export data to a format known by the tool of the translator (e.g., XLIFF). Web-based tools do not have that drawback. The translator just uses her browser to work with the project. However, the web-based tools have very shallow support for file formats. Basically, they can only work with XML and JSOM base formats. In addition, you have to send your files to the service or let the service to access your repo. I personally do not like either of the choices.
Soluling brings the best of both worlds. Soluling has all the benefits of the desktop tools: easy creation of the project, full access to all files, rich Windows-based UI. When you want to localize a file, application, or database, you first use Soluling GUI or Soluling command line to create a project. That creates a Soluling project file, .ntp. It is an XML based file that contains information about the files or project you want to localize, plus all the extracted strings of those files. In addition to the resource files, Soluling knows the project files too. For example, if you want to localize an ASP.NET Core application, you just add your .csproj or .sln file to the Soluling project. Soluling reads the project file locating the resource files and then extracts strings. If you later add a new resource file into your project, you don't have to modify your Soluling project. Once the Soluling project file, .ntp, has been created, you add that to the same repo with your source code. Then, in your build process, you use the command-line version of Soluling to maintain and update the project file. This means that before you build, you tell Soluling to rescan the project. If it finds new or modified strings, it adds them to the project file. This project file can then be sent for translation. You have several choices. You can use one of the then supported machine translator (DeepL, Google, Microsoft, etc.) or send the .ntp to your translator. The build process can also upload the project to the Soluling cloud when the translator can use Soluling's browser application to translate it. It will also be possible to order translations from Soluling's professional translators.
During the build process, the build server or DevOps pipeline uses Soluling's command line to create localized files. This process uses the current translations found in the .ntp file. If the .ntp had been upload to the cloud the process first export the most recent translation from the cloud and imports them to the local .ntp. This way the local .ntp is the snapshot of the cloud project. Soluling creates the localized files, localization application or resource files. Everything created by Soluling is ready to be deployed. There is no need to post process them.
Soluling supports more file, application, and database formats than any other localization tool or service. You can see the full list of the supported formats here.
You can use Soluling without the continuous localization process just by starting Soluling GUI, opening the file and performing the scan, export, import, and build operations.
Soluling brings the best of both worlds. Soluling has all the benefits of the desktop tools: easy creation of the project, full access to all files, rich Windows-based UI. When you want to localize a file, application, or database, you first use Soluling GUI or Soluling command line to create a project. That creates a Soluling project file, .ntp. It is an XML based file that contains information about the files or project you want to localize, plus all the extracted strings of those files. In addition to the resource files, Soluling knows the project files too. For example, if you want to localize an ASP.NET Core application, you just add your .csproj or .sln file to the Soluling project. Soluling reads the project file locating the resource files and then extracts strings. If you later add a new resource file into your project, you don't have to modify your Soluling project. Once the Soluling project file, .ntp, has been created, you add that to the same repo with your source code. Then, in your build process, you use the command-line version of Soluling to maintain and update the project file. This means that before you build, you tell Soluling to rescan the project. If it finds new or modified strings, it adds them to the project file. This project file can then be sent for translation. You have several choices. You can use one of the then supported machine translator (DeepL, Google, Microsoft, etc.) or send the .ntp to your translator. The build process can also upload the project to the Soluling cloud when the translator can use Soluling's browser application to translate it. It will also be possible to order translations from Soluling's professional translators.
During the build process, the build server or DevOps pipeline uses Soluling's command line to create localized files. This process uses the current translations found in the .ntp file. If the .ntp had been upload to the cloud the process first export the most recent translation from the cloud and imports them to the local .ntp. This way the local .ntp is the snapshot of the cloud project. Soluling creates the localized files, localization application or resource files. Everything created by Soluling is ready to be deployed. There is no need to post process them.
Soluling supports more file, application, and database formats than any other localization tool or service. You can see the full list of the supported formats here.
You can use Soluling without the continuous localization process just by starting Soluling GUI, opening the file and performing the scan, export, import, and build operations.
Tilaa:
Blogitekstit (Atom)
