Okay, as far as I would understand, the en language files are the basis. If another language file, say de, is missing a key, then the system would revert to the value for that key in the en file. Am I right in saying that? I am wanting to add translations, so I exported en and de, since I can read both languages. I wanted to do some comparisons on how things are translated so that I maintain consistency with the new languages. It's understandable that there are a bunch of keys in en that are not in de, but there are also three keys in de that are not in en? Code: --|sites|de|de.lng $wb['Backup Stats'] $wb['Database quota'] $wb['FTP traffic'] Can I translate these keys from de to en and then into each language I want to add? Or am I missing something? Also, in the en language files there is a key that has a value containing a single double quote. Code: $wb['username_error_collision'] = 'The username may not be web or web plus a number."'; The de language file has this string translated but doesn't contain the rogue double quote.
Yes. They are not in the English file as they are already in English. There can always be minor differences in the files. The double quote can likely be removed; it is likely that the file was mass-converted to single quotes, and that double quote slipped through. Create your language file, test it, and you will see if your language file works or not.
Okay cool. I also found a lot of duplicate entries in the en file. I will create an updated and tested en.lng and revert. Regarding new languages, I am cross referencing which words must not be translated by doing a line by line check between en and de. As I said prior, I can read German so that's why I chose de. I will create a set of rules for translation. With my work with AI in my AI Business, I have trained an AI model for technical translation between English and major South African languages. Words to remain in the original form must be encased in $ symbols, and then my AI keeps it in the original form. I will test with Afrikaans, then run af.lng backwards to English and verify that everything translated. Any lines that pick up an issue I will get in a log file which I can then go over manually. Once I know my AI works, we can use it to do any language I train it on, and I have training data for about 130 languages.
Finished the code for training technical context between en and de. Looking forward to testing it on a new language. Obviously not on my production server. I don't have a GPU anymore due to mine going pop, so training using CPU which is a tad slow. It's doing one language entry per second approx. But I am getting 470 context rules + 191 rules for nouns that switch to capital first letter in German. I am saving these rules to, incase I need them in the future.
Context Training just finished: 953 data points. I am going through them by hand removing things like integers, html tags and urls... and anything else that the AI wouldn't consider. Once done, I can take a line from en.lng, encase a term that must not be translated, then get the translation of the line, write it to newlang.lng Once translation for Afrikaans is complete, I will translate af.lng back to English and compare each line and any that do not translate back correctly will be flagged so I can see if I have to do further training. Holding thumbs...
@till How does ISP Config select the flag for a country? I used the official ISO 639 code for Afrikaans, and it displays the Afgan flag? Maybe there should be an additional headers in the completed .lng file where we can put Country Name, Country ISO 3166 Code, Language name, or some other metadata? I am happy to dig into the source and see what we can do it make it work. Also would be nice then to have Languages display as the language name rather than af or de or en. I can curate a php data file or a JSON file that contains all the languages covered in ISO 639 and has the Language name Country name, ISO 3166 code, etc.
ISPConfig currently uses the iso country code, not the iso language code. So in your case, the right name will probably be za_*.lng. ISPConfig contains a database table with all iso codes.
I'm aware that there is an issue in such a case, but the language system is like that at the moment, and we can not change it in ISPConfig 3 easily, as this would also affect many third-party software. Basically, you could just use any free 2 letter code for your customization and add it to the languages table.
okay, future problem for a future fix. I was hoping to submit these two language files but it may cause conflict or confusion for others.
