How interface differs from intermordia: our approach to documenting and localizing software products
Once, in the technical documentation for Parallels Desktop, we needed to use the phrase “ virtual machine hard disk ”. In English, it sounds: virtual machine hard disk . Our past technical writer made a mistake in just one letter in one word, but the meaning was diametrically opposite. We noticed this not immediately and at some point our technical documentation, localized in many languages of the world, contained imperishable: virtual machine hard dick . There was a huge scandal, after which we tightened the verification of texts. Under the cut is the story of our technical writer Andrei Starovoitov about where technical writers live, what to catch them on and how Parallels documents and localizes its products.
Perhaps you have a question - why do I, the developer / programmer / tester, need to know how the documentation and interface are created and localized? Everything is very simple: life can suddenly turn to you so that today you are a programmer, and tomorrow you will start your startup, in which you are both a Swiss, a reaper, and a technical writer. It is also possible that taking a managerial position you will suddenly have to control the process of developing technical documentation.
Part 1: Where to find a technical writer or humanitarian in the rear of techies
Technical writers are not trained at universities. If you need such a specialist, you can invite him from abroad, or "grow" in the company. Below we dwell in more detail on these options.
Foreign specialist
Pros :
If you plan to sell the product abroad and need documentation in English, a native speaker will describe the application in a better quality. This is not to say that a domestic employee with knowledge of the language will do it necessarily badly, but if you approach the issue from the point of view of perfectionism, then for some phrases, turnovers, and building sentences, foreign users can understand that the documentation was not written by a native speaker. Cons :
Firstly, a foreign specialist will have to pay more. And secondly, not every foreigner will agree to come to work in Russia. If he works remotely, in isolation from the developers, then delays in the timing of the preparation of documents and technical inaccuracies are possible, since remotely it is always more difficult to find out the technical details than if you talk to the programmers directly.
The writer "who grew up"
Here the question arises, from whom to grow - techie or humanities? Of course, it all depends on the specific situation, but let's look at the main points.
"Techie" Pros : Techie better understands the filling and technical details, or is it easier for him to understand. Cons : Not every techie will want to bother with the documentation, because the developer is more often focused on some narrow area and sees himself as a Sculptor, rather than Evgeny Onegin, “who can touch only slightly with the scientific look of an expert”. "Humanities" Pros :
It all depends on the specific case, but the humanities can better describe the product, as it speaks a better language. And yet such a moment, the developer can describe the function or feature in two sentences, since with his store of knowledge he already understands everything. For the buyer of the product, such a description may not be enough. In the humanities, as a layman, various questions arise in the description. If he finds answers to them and describes the product function in such a way that he himself understands, then such documentation will be more understandable to the user. Although, again, it all depends on the specific situation, if the manual is written for administrators, it would be unnecessary to explain to them what the IP address is. Cons :
The downside of humanities is that it knows less about the technical side of the product, and it will take time for it to master the terminology, learn the basics and begin to understand what's what.
Personal Experience
- I ended up in Parallels very prosaically. After school, he studied at a teacher training college in the city of Serpukhov as an English teacher. After at the Moscow State Linguistic University. Maurice Thorez. When the question of serious work arose in the third year of the university, I already managed to be a courier for DVD distribution, a warehouse clerk, a warehouse manager, and a sales manager. All this was good, but the desire to earn a living in English was stronger. I did not go into teaching, because I wanted to work in some applied field - oil industry or IT.Once, on one of the job search sites, I saw a vacancy - an assistant technical writer for SWsoft with the possibility of career growth. The announcement talked about participating in the creation of documentation for computer programs. Writing documentation was required immediately in English. For me it was something completely new and interesting. I sent a resume, went through an interview, wrote an essay on a free topic, and so became a junior technical writer.
At first it was not easy. Being a humanist to the marrow of bones, when writing the first topics, it seemed that everyone around spoke some kind of bird language. I did not know the terms at all. The conversation with developers at first looked something like this :
- Hello, I'm a new technical writer. I need to describe this functionality. Could you tell us in more detail how it works?
- Well, everything is simple here, the client “connects”, if the “server” is not dead, everything is fine. If anything, you can "ping." There is a “bug shooting”, “the container is hanging out,” but here the “patch” can be rolled. Take this "executable", it is on the "turnip" among testers. Got it? Well done.
or so:
- I need to describe a feature here, it is associated with Active Directory. Could you tell me what it is?
- Yes, this is the same as LDAP on Linux.
At first I wrote down all these terms in a notebook, then I went to “google” the meaning. After that, I again went to the developers or testers and asked in a new way. For the first six months, in my free time from work and study, I studied terminology, read what automation, virtualization, containers, virtual machines, RAM, a processor, IP address, DHCP, etc. are. Then, unexpectedly, the quantity turned into quality and I began to feel freer in this area. If I didn’t understand something, Google had enough for me to grasp the main idea, and I went to developers mainly for details.
At the moment I have been working in the company for about 8 years. He grew up to a senior technical writer. Now I am not only creating documentation and an interface, but also translating them into supported languages.
Part 2: How we create technical documentation
3 people are working on the creation of the documentation - two in Russia and one employee in the USA, for whom English is native. To write technical books, we use the AuthorIT product . It is quite convenient to work in. The library with books lies on the server. Each writer has a client part on the computer with which he connects to the library. This allows multiple writers to work on one book. Using options makes it easy to create books for new versions of products based on old ones.
It’s hard for me to say anything about other products in which you can create documentation, because historically, we work at AuthorIT. He is happy with us so far, and switching to another product just out of curiosity may turn out to be an expensive pleasure. For example, the same AuthorIT subscription for 3 people will cost $ 375 a month or more.
Since our main sales market is abroad, we write the documentation immediately in English. Since English is now considered the universal language in the world, special attention should be paid to ensure that there are no problems in the English documentation. Of course, one could write in Russian, and then translate into English, but this will make it necessary to check how well the translation is done.
We would not want to spend resources on this, since we have the opportunity to write immediately in English and at the same time check that this English is understandable and looks as if the text was written by a native speaker.
The process of creating documentation is structured as follows:
1) Marketing with managers discuss a list of functionalities and improvements that will be introduced in the new version of the product.
2) For each task, the manager writes a detailed description.
3) After the programmer implements the functionality, I put the latest version of the program on the computer, read the description, try how the new product works and describe it in the manual. If you have any questions, I communicate with managers or developers.
4) I describe the new functionality in English, and then send the topics to our foreign writer for verification. He reads and, if necessary, makes any changes. It seems that I know English well, but still a native speaker can sometimes express herself more concisely and succinctly.
5) After verification, the foreign writer sends the topics to me, I upload them to the database and publish the documents in the required formats - basically this is PDF and XHTML for contextual help (this is when you click on the icon with a question mark on the screen and the topic attached to this screen opens the help in the browser).
6) When the English documentation is ready, I send it for translation. About how and in which languages we translate, I will tell below.
What documents are created for the product:
User's Guide- This is the largest book for the product, which describes all the functionality, tricks and solutions to possible problems. It is targeted at most users.
The Getting Started Guide is a short document that describes the installation procedure and the basic steps necessary to get started with the product. It is focused on getting to know the product and users who have some experience and want to quickly start working with the application without introducing themselves into additional settings and subtleties.
Readme is usually a text file that is created for each release, hotfix and update. It describes what has been done, what has been improved and what problems have been resolved.
Knowledgebase articles- These are articles for the so-called knowledge base. They describe either some points that cause frequent questions from users or temporary solutions to known problems.
There are also various other types of books, such as:
- Licensing Guide (describes how to create an account, manage your key or subscription, etc.)
- Administrators guide (a document for people with technical experience for product deployment in large companies)
- Training manual (a document for people who teach users how to work with the product)
- Command Reference Guide (it describes commands for a text string and gives examples of their application)
-API Reference Guide (such books document APIs).
What tools we use to create documentation:
- AuthorIT - a program for creating and working on books.
- Adobe Photoshop - to create and work on screenshots for documentation.
- Microsoft Visio - to create schemes.
- Microsoft Word and Adobe Acrobat - for publishing documents in .docx format and subsequent generation in PDF.
There are various oddities in the work of creating documentation. Mostly related either to the carelessness of the writer or if something is done in a hurry and is tritely missed. For example, there were cases when ready-made documentation was issued in which the writer’s comments were not deleted, for example, “Verify with Vasya how this garbage works”.
And it also happens that the writers themselves are kidding themselves in the documentation for internal use. Some people believe that nobody needs documentation, since nobody reads it. Sometimes a writer in some unofficial document for a company may write in the text of instructions - “whoever reads this first and calls me will win a beer”.
Part 3: How a technical writer can contribute to creating a GUI
In the process of working on features, developers often need to come up with the option name, menu, description under the option, or an error message. Since we make gui immediately in English, developers entrust this task to me. I read the description of the feature, ask developers and managers what we need to say, find out the details and offer my English version. If he is technically correct, I send it for approval to our foreign writer and inform him of all the details that I found out from the developers. He, in turn, either approves my option or offers something of his own. If the final version suits everyone, it is poured.
In the process of creating a gua, we adhere to the following points:
1) You need to try to make the names of the options understandable and short in order to avoid subsequent problems with their localization when the translation does not fit. For example, we have an option that slows down the mouse cursor at the border of the virtual machine window. This was done so that the user in Windows 8 could more easily open additional menus that are near the border. Without this option, the user often simply moved the cursor abroad and the cross-border menu was not displayed. So, we thought for a long time what to call this option, it turned out either too long or not entirely clear. As a result, we settled on “Mouse sticks at window edges”. Of course, there are times when it is difficult to come up with the ideal name for the option, in such situations you have to choose a more or less acceptable option and hope that if the user does not understand, then read in the documentation.
2) If the message uses complex terms or describes the time-consuming process of how to solve a problem, it makes sense to give a link to the KB article or some other resource where there is a more detailed and detailed description or explanation.
3) When creating a message, you need to concentrate not on the fact that it did not work out, but on what needs to be done so that the desired result is achieved.
Part 4: Translation of technical documentation and GUI
After the development of a new version of the program has begun, usually the first batch of help topics and gui phrases that can be sent to localization are accumulated by Beta 1 / Beta 2.
In my opinion, it’s very cool if the very writer who wrote the topics and helped make the guy will manage the translations and communicate with the translation office. Such a person competently plans work, knows better when it will be written, or how soon something needs to be described. He knows the meaning of phrases and can more easily and quickly answer translators' questions.
I remember we used separation before - there are people who write, and there is a person who deals only with localization. As a result, processes were not always effective. For example, the writers described the features, their task in Jira closed and calmed down. But forgot to note all the topics that have been changed. As a result, the localization manager did not send everything for translation, and as a result, it was necessary in the wild rush to translate the missing. Or the localization manager sent the translation to the translation, but he did not create it, and cannot answer the many questions of the translators. It starts to yank different people, and they still need to be found, because part of the gooey was made by the Tim server, partly by the devices, partly by the guishers, partly by the integrators, in short time loss and not detailed answers - as a result, insufficient translation quality.
We translate the documentation and gui of our products into the following 12 languages: German, French, Italian, Spanish, Polish, Czech, Russian, Portuguese (Brazilian), Japanese, Korean and two versions of Chinese - simplified and traditional Taiwanese.
Then the question may arise - how best to have your own translators or use the services of a translation company. Let's see the pros and cons of both options.
Own translators
Pros :
If you have translators in your staff, then they usually know the product pretty well and are therefore able to make better translations. Cons : As a rule, the most active stage of product development, when you need to do a lot of translations, lasts 3-4 months. In such a situation, everything needs to be considered, because it may just be economically unprofitable to keep translators on an ongoing basis.
Translation office
Pros :
We send them tasks when development is in full swing, and pay only for the completion of these tasks. As a result, this is cheaper than having 12 translators on staff. Cons : Often the translation office works not only for you, and one translator can deal with your order today, and tomorrow it will be completely different. He about your product may absolutely have no idea. In order not to lose quality in translations, one has to write a lot of explanations for translators, so that they have an idea of what they are translating and what to pay attention to. We use the services of one of the European companies. She has her own body of translators in different languages. All text materials are sent to the contractor. Formats can be very different:
• when localizing the GUI - .txt files, .strings files, .xml files, .xliff files,
• when localizing the documentation - .docx files, .xml files
First of all, it is necessary to localize the GUI. For each portion of the translation goof, I prepare detailed comments for translators - for each phrase. In the comments I describe what kind of phrase it is, how to translate it - by the infinitive or imperative, whether it is necessary to translate as short as possible (especially if it is a button) and if so, how many characters should fit. I also send screenshots to translators so that they can see how an option or message looks in a gua.
Why the first thing to do is translate Gui
The fact is that the translated phrases fall into the so-called translation memory - translation memory. From this memory they will subsequently be taken if in the subsequent portion of phrases for translation it turns out to be exactly the same. For example, we translated the gui and settled the options in length. After that I send the documentation for translation in which these options are described. So, the translation of these options for documentation will be taken from the translation memory, and thus the phrases in both the gui and the documentation will be translated the same way. If I translate the documentation first, and then gui, then if the option is too long in the gui, I will have to edit both the gui and the documentation so that it is consistent everywhere, and this is an extra crap.
As soon as the translators are ready, they send me the translated materials, I import them into the databases, from where then the localized guy and the documentation get into the build.
How does a translation agency work?
Having received materials from us, the contractor runs them through his database of completed translations - the so-called translation memory. The system looks for whether there is data in the new material that was once translated. As you find these finished fragments are inserted into the text. Suppose, if three of the four sent paragraphs were already translated for the previous release, then it’s enough to translate only the fourth paragraph, and the rest to take their database. This saves both time and money. So the first portions of materials are translated the longest, with the most changes and a new text.
There is one peculiarity in working with localization companies: they need to send as much material as possible at a time. If you make orders that are too small in volume, this can be much more expensive.
Why it happens?
Each localization company has its own minimum transfer volumes. If after running through their database it turns out that you need to translate too little text, then the invoices are not issued for the translated words, but for the hourly work of the translators. And since with the approach to the release date the portions of texts requiring localization are becoming smaller, you have to maneuver, holding materials in order to accumulate more and not overpay. At the same time, it is important not to break the deadlines by rolling out a large transfer order a week before the release.
Cost of localization
Perhaps you are interested in how much companies spend on localizing their products? It greatly depends on the size and language chosen. For example, the cost of translating one word into Polish is $ 0.14, into German - $ 0.23, into French - $ 0.21. We have large and complex products, with weighty documentation that needs to be translated into 12 languages. Therefore, the total cost of localization is on average $ 10-60 thousand. Moreover, this does not include the costs of translating articles from knowledge bases (knowledge base), which describe various working methods, as well as the localization of changes on the site.
"Gentlemen take the word"
Given the diversity of languages and the high cost of work, how can you evaluate the quality of the translation? What if the contractor simply ran the text through Google Translate and the result was aligned?
The fact is that in the field of localization, reputation is extremely important. When companies are looking for contractors to translate documentation and interfaces, they approach this very carefully. For example, we selected from about 15 companies: we sent out test assignments to everyone, and then checked the translations we made for our employees from different countries who understood these languages. We also paid close attention to reports on the work performed: how detailed is it, how many words have been translated, how many new words have been found, are there cases when only part of the sentence needs to be translated, and so on.
In the end, we chose one of the companies as our contractor and started working with it. But this does not mean that we have since taken their word for it. The quality of translations is regularly checked by:
• our employees who understand the relevant languages,
• translators of the contractor. The fact is that some translate there, but others read at our request.
Surely you will say that you need to check the work of one company with specialists from another. But the fact is that localization companies are desperately fighting for customers. And if we send texts to someone and ask them to evaluate, they will immediately tell us that it has been badly translated, let us do much better. Actually, attempts to lure us do not stop so far.
Sometimes, when a big release comes out, it’s not always possible to check the documentation localized shortly before the deadline. Then you have to release it at your own peril and risk as is. But in such cases, we work closely with support: if there are any schools in the documentation that receive complaints from users, then we immediately turn to the translators and redo them. Fortunately, this rarely happens.
Translation Issues
In the process of working on translations, certain jambs may occur. All of them must be carefully discussed with the translation office, so that they sorted it out and this did not happen again.
1) Inattentive translator - if a phrase has a variable in the phrase, an inattentive translator may skip part of it. For example, you have a variable (% 1) s, and in the transfer you get (% 1). As a result, the phrase will not look as it should.
2) The translator thought about it - we are all human, it happens that the translator will translate something incorrectly, and something rather simple. For example, the phrase This file is not valid will be translated as “File not found.”
3) Too thorough translator- such a translator translates everything that he sees. Here it is necessary to explain that the ProductName variable must be translated as "Product Name", otherwise it breaks and product names are not substituted in the gui. Or if it translates an .xml file with documentation, then you do not need to translate the tags and, otherwise, then such xml will not be imported into the database due to broken tags.
4) A difficult technical term or abbreviation - if there is something similar in the text of the translation, it is better to immediately draw the attention of the translators in the comments, describe what it is and advise google to find out how it translates correctly into their language. Otherwise, you can get something far from the desired term.
5) Shoals due to lack of comments- if you do not make comments for translators, they may not ask questions for all obscure points. As a result, the quality of translations may suffer. For example, we have a Parallels Access application that allows you to access remote computers from iOS and Android devices. Another product has a tab that allows you to download this application. This tab is called Access and should not be translated. We did not have time to make comments then, as a result, the Czechs and Poles quickly translated it, where as “access”, where “attack”.
6) Too responsible translator- such a translator himself can insert punctuation marks that do not need to be inserted. For example, we have a colon in one product and the period at the end of the sentence is inserted automatically - as it is written in the code. As a result, we sent the phrase without dots and colons at the end to the translation. The translator in the translation himself decided to put dots at the end, and we always had double dots. Or the translator can think up and add the text of the phrase. For example, there is the phrase Unable to save the license file. I explain in the commentary that it is shown when, for some reason, we cannot save the license file for the Parallels Desktop product. There comes a translation - “Failed to save the license for Parallels Desktop.” We have to explain that you don’t have to think up and it’s better to limit yourself to the phrase “Failed to save the license”,
7) Translation is too long - you get sometimes a portion of the translated gui before the release, you fill in the translations, and in the gui half of the options do not fit - they translated too long. Here you need to react according to the situation - either urgently ask translators to shorten the translation, or ask developers to expand the window, because if you shorten the long phrase to "tyr.pyr.myr.", It will turn out ugly and incomprehensible.
8) Incorrectly calculated terms - sometimes there are situations when you send files for translation and think - well, then they will translate in 3 days, at most. And they roll out a term for you - a week, no less. Therefore, I made it a rule - by the expected date add 3-4 days just in case.
9) Holidays in other countries- This is also related to the timing. Typically, the localization company warns, and this must be remembered - where, when and who has public holidays. And sometimes you need to urgently translate something into Chinese, you think - well, it's me in an instant, and they tell you that they have a new year now. They promise to try to find a way out, but as a result, a similar situation may also turn into a delay.
10) Developer - optimizer- sometimes you have to wage war with the developers. Their code optimization is a fix idea. They are very fond of reusing the same data. For example, they will insert a phrase or word in one place, and then they will be referenced from various places. I had such a case. The application has a tab where you can reassign keyboard shortcuts. In particular, there is a shortcut Ctrl + Alt + Delete. And we also have a snapshot manager that allows you to delete these snapshots. What is characteristic, the button is called Delete. The developer who wrote this manager, instead of calling the shortcut Ctrl + Alt + Delete and the Delete button separately, came up with optimization: in one place in the code he called the Delete button, and the shortcut called Ctrl + Alt + <this button>. And when we began to translate the interface, the Delete button was translated into all languages. In the Russian version, this shortcut became known as Ctrl + Alt + Delete. I had to write the names of the button and shortcut separately in the code. Another example. When we released Parallels Access, the phrase “Welcome to Parallels Access” was on the start screen. In theory, it was necessary to register it in the code as is. But since the phrase used three different fonts, the developers broke it into three parts: Welcome, to and Parallels Access. And when displayed on the screen, the phrase was assembled from these parts. When it came to translations, the Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code. I had to write the names of the button and shortcut separately in the code. Another example. When we released Parallels Access, the phrase “Welcome to Parallels Access” was on the start screen. In theory, it was necessary to register it in the code as is. But since the phrase used three different fonts, the developers broke it into three parts: Welcome, to and Parallels Access. And when displayed on the screen, the phrase was assembled from these parts. When it came to translations, the Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code. I had to write the names of the button and shortcut separately in the code. Another example. When we released Parallels Access, the phrase “Welcome to Parallels Access” was on the start screen. In theory, it was necessary to register it in the code as is. But since the phrase used three different fonts, the developers broke it into three parts: Welcome, to and Parallels Access. And when displayed on the screen, the phrase was assembled from these parts. When it came to translations, the Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code. on the home screen was the phrase “Welcome to Parallels Access”. In theory, it was necessary to register it in the code as is. But since the phrase used three different fonts, the developers broke it into three parts: Welcome, to and Parallels Access. And when displayed on the screen, the phrase was assembled from these parts. When it came to translations, the Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code. on the home screen was the phrase “Welcome to Parallels Access”. In theory, it was necessary to register it in the code as is. But since the phrase used three different fonts, the developers broke it into three parts: Welcome, to and Parallels Access. And when displayed on the screen, the phrase was assembled from these parts. When it came to translations, the Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code. Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code. Japanese ofigeli, but faithfully translated all three parts separately. Only problem is that in Japanese the text is read from right to left. And instead of “Welcome to Parallels Access,” they ended up with “Parallels Access Welcome.” I had to change the code.
11) Different endings of nouns depending on the numeral- I remember somehow we had difficulty translating phrases in which there were numbers. For example, developers need to make a phrase like “Trial period ends after so many days.” In English, everything is simple - “Your grace period expires in% 1 days.” The problem appears when translating into languages in which the endings of nouns change depending on the numeral. For example, in Russian - “the trial period ends in 5 days / 3 days / 1 day”. First, we substituted various crutches (we used abbreviations in the translation, for example, days - to “days”, minutes - to “minutes”, seconds - to “seconds”) or collective farms (changed the English phrase to “Days left until the grace period expires:% 1. ”. Then we all the same took the time, filled in different versions of word translations that are often found after numerals (for example, (5) minutes, (3) minutes, (1) minute),
Verify localization before release
No matter how carefully comments are made for the translation, but there are still various jambs, so it’s good to check the quality of localization before the release.
You can check in one of the following ways - either give the translators a program and scripts for which you want to check, or provide screenshots of the product and scripts. Again, each of them has its pros and cons.
Live Build Check
Pros : The
translator receives scripts in which he, as a regular user, drives a product and notes where which name or message needs to be changed or corrected. In this case, the translator also acts as a tester and there have been cases when translators found bugs that were not related to localization. This type of testing is easier to prepare than for screenshots, since only English instructions need to be compiled, and there is no need to take a bunch of screenshots for 12 languages. Cons :
This type of testing is more financially expensive. Often, translators do not have the necessary equipment, so they need to pay extra to rent it. They will also spend more time checking a live build, you have to pay for every hour. Plus, when they start chasing a live build, as a rule they don’t succeed in something, and it takes time to answer the numerous questions of 12 translators.
Screenshot Verification
Pros :
Less costly in finance. You send translators English instructions and screenshots, as well as localized screenshots in the same order as English ones. As a result, the translator reads the instructions and compares the English screenshots with the localized ones, and notes what and where it would be nice to fix. Such work also needs to be paid by the hour, but it takes much less time than checking a live build. Cons : You must carefully prepare for this type of testing. It is necessary not only to make detailed English instructions, but also to take the same screenshots for each language, and there are 12. There is a lot of time to spend.
In the final, I want to say that, of course, creating a simple, convenient and understandable software product that would also sell itself is the dream of any developer. In reality, everything is different. Along with the development of your product, like the underwater part of an iceberg, dozens of related tasks appear, and you can consider them insignificant for a while. We sincerely hope that this article was of interest to you. We will be pleased to answer additional questions in the comments to the material.
Z.Y. And the last hack!
