Three or four sources really.
1. CrowdIn.
2. The personality in use.
3. The voice in use.
4.Our Humanise() function (if you're using that)
Are you having problems with numbers from the Humanise() function? Are you using an Italian voice?
Release EDDI 3.3 - Bring your cockpit to life
- Thread starter VerticalBlank
- Start date
1. CrowdIn.
2. The personality in use.
3. The voice in use.
4.Our Humanise() function (if you're using that)
Are you having problems with numbers from the Humanise() function? Are you using an Italian voice?
Since the default Italian personality is untranslated from English, it is being kept current with the English translation. All script updates have been mirrored over. If the community provides a translation to Italian (either by submitting a revised eddi.json or by submitting a pull request against https://github.com/EDCD/EDDI/blob/develop/SpeechResponder/eddi.it.json) then we can incorporate it. The personality would become the Italian community's responsibility to support and maintain from that point.
Note: The submitted personality should ideally have the same scripts as the English version. Adding new scripts to the default in your language creates some complications that we'd rather avoid if possible.
yes, and yes (IVONA Carla, but the "wrong" numbers comes the same with the default italian win voice).
Ok, so some voices are better than others? With IVONA Carla (which I'm understanding to be better than the Microsoft voice), is
1000 correct without Humanise()? If so then our goal should be to return 1000 rather than 1 mille? Unfortunately, that would in some cases likely be more verbose and so we'd need to carefully consider.
Last edited:
All the italian voices i own are the same, about these numbers, so the problem is in the Humanise function.
Yes, you should left 1000, 1000000 and 1000000000 untouched, or convert them in mille, un milione, un miliardo (note that "un" is not = "one" but is an article, like "a").
We also have "un migliaio, due ... migliaia" (= "a thousand, two ... thousands") and "un centinaio, due ... centinaia" (= "an hundred, two ... hundreds") when the quantity is not precise.... the same when you use "a dozen".
What kind of "humanisations" should i test to see if there's other things to address? i see how the function convert numbers in ... "colloquial quantities", but i don't know what to test.
PS
Why there's a "di" (= of ) after "milioni"? (milioni di = millions of)
Last edited:
Ok, we can leave it to the voice to interpret 1000, 1000000 and 1000000000 on the next release. More complex numbers would still be rendered as they are.
"di" is from the CrowdIn translations.
While keeping the same scripts, how much "freedom" there's INSIDE the scripts?
Some options (OneOf functions) are not available in italian, or some phrase parts needs to be reverted, and then there's some subjective choices about how better is a phrase kept "closer" to the original english one or rewritten.
Also, some script shows a certain "style" (some scripts have the phrase parts stored in variables, and then queued, someone else uses
` around the spoken parts instead of ", some scripts are divided in "sections" using comments, etc.What "style" should i follow, and how much i could "move" the various part of the script inside of it?
Last question for a while (sorry)
This is part of a script:
There's a reason (resources, execution time, ... ) for the
This is part of a script:
Code:
{if materials = 1:
{blueprint.materials[0].material}
|elif materials = 2:
{blueprint.materials[0].material} and {blueprint.materials[1].material}
|else:
{set cur to 0}
{while cur < len(blueprint.materials):
{if cur = 0:
{blueprint.materials[cur].material}
|elif cur < len(blueprint.materials) - 1:
, {blueprint.materials[cur].material}
|else:
, and {blueprint.materials[cur].material}
}
{set cur to cur + 1}
}
}There's a reason (resources, execution time, ... ) for the
|elif materials = 2: branch? That case is already covered in the while loop below, so i don't get why it is there (and it adds translations to do -as little as it is- so it add maintaining efforts).
I think the problem with the 'style' is because the scripts have been written and amended by different people over time. Some parts come from the original author of EDDI, JGM, while the majority come from the current team, and it seems that each member has their own 'style'. This has always bugged my 'coding OCD'
and for my EDDI personality, I've spent a long time going over every script to give them all a standardisation to their code. For me at least, it makes it easier to understand what's going on; if I see a code block in one script, I know that will be in another script doing the exact same thing, rather then be coded in a different way to achieve the same result.For mine, I've tried to standardise the code, variable names, the layout, and many other little things. It would be great if the default personality could be standardised too, but I feel this would be a big undertaking for the team, and their time would be better spent bug fixing and updating instead. It could still be done, I guess, if someone was willing to go through the whole personality, and standardise everything to a certain set of rules. But as you say, for different languages, the code would need to be re arranged and laid out differently, due to differences in language grammar.
I think it's execution time (efficiency), but it's literally just microseconds. I must admit, for my personality, I removed the first couple of options, and have just left it all to an efficient, standardised WHILE loop. For me, less code to look at is tidier.
This is one of the things I've standardised across all scripts throughout my personality.EDIT: This is my version of that part of the code:
Code:
{set cur to 0}
{set length to len(blueprint.materials) - 1}
{while cur < len(blueprint.materials):
{blueprint.materials[cur].material}
{set cur to cur + 1}
{if cur = length: and
|elif cur < length:,
}
}
Last edited:
OneOf() should work in Italian. What do you mean when you say it isn't available?
As far as translation freedom within the scripts is concerned, we recognize that flexibility is needed to provide the best translation and trust the judgement of our translators. I agree that the scripts don't all have the same style, and we actually prefer this. Part of our goal with our default scripts is to demonstrate various methods for writing scripts so that commanders can learn how to use the Cottle scripting language and to provide examples which commanders can modify to their liking.
The Cottle scripting language prefers to see
" and ' alternate when nesting one function inside another.We'd rather not pop up a message box as that could be quite disruptive while you're in game, but the error details should be recorded in EDDI's .log files located at %APPDATA%/EDDI.
Hi Parduz, one thing to understand. The character EDDI is the original character and it is in English.
You have to copy and rename EDDI once and then you can translate, shorten or extend the scripts to your liking.
You can do that without any problems. This also means you can adapt the pronunciation to the Italian pronunciation.
A few CMDR from Germany have been doing this for quite a long time.
Your copy of the character does not bother the makers of EDDI at all.
Greetings from nepomuk
Translated with www.DeepL.com/Translator (free version)
You have to copy and rename EDDI once and then you can translate, shorten or extend the scripts to your liking.
You can do that without any problems. This also means you can adapt the pronunciation to the Italian pronunciation.
A few CMDR from Germany have been doing this for quite a long time.
Your copy of the character does not bother the makers of EDDI at all.
Greetings from nepomuk
Translated with www.DeepL.com/Translator (free version)
Oh, sorry for have not been clear: i means that sometimes english can use different words (hence the OneOf) while in italian we have just one, so i have to remove the OneOf function.
Anyway, i got the reasoning behind the scripting styles and freedom about them.
Yup, i was surprised about
` (which is ALT+96 on my keyboard).Understood. I was thinking at the popoup only when the editing form is shown, but i get that it is not so useful.
Yup
My own WIP personality is a different file, and she uses "we" and "us" instead of "you"
looking at the "Message Received" script: from where "Squadron mate", "commander" (and i don't know if there's other titles) comes?
'cause they're not translated, and i can't find them on Crowdin.
-edit-
found it: {event.source}. Now, why the words in it aren't translated?
'cause they're not translated, and i can't find them on Crowdin.
-edit-
found it: {event.source}. Now, why the words in it aren't translated?
Last edited:
Likely something that got missed when we implemented internationalization. Please open a ticket. o7
We're pleased to announce that EDDI 3.7.2-b2 is now available for all users from within the app and from https://github.com/EDCD/EDDI/releases/download/Release/3.7.2-b2/EDDI-3.7.2-b2.exe. 
This release touches up rendering of simple whole numbers with the Humanise() function (to support easier translation) and touches up a number of scripts.
Full release notes are at https://github.com/EDCD/EDDI/blob/Release/3.7.2-b2/EDDI/ChangeLog.md.
Thank you
This release touches up rendering of simple whole numbers with the Humanise() function (to support easier translation) and touches up a number of scripts.
Full release notes are at https://github.com/EDCD/EDDI/blob/Release/3.7.2-b2/EDDI/ChangeLog.md.
WOZZ
Problem is that, while now that numbers are ok, it is'nt the spoken umanization.
From english "more than two thousands and half light years" (i'm guessing, here, as i don't hear it in english) it translates to "più di due e mezzo mila anni luce" but it is wrong, as it should say (staying literal) "due migliaia e mezzo di anni luce". I see how that Humanise function is beatiful, but also how hard it is to be localized: (perhaps?) it should pick from a a table of localized phrases, not just translating words...? I really dunno, i'm just saying that it is hard to make it works for all languages but i love the idea of the Humanise function.
AFAIK, the Humanize function is English based, and for that, it doesn't draw upon a table. I believe that proper localization would require a function written from the ground up with a particular language in mind, or from the ground up with a completely ambiguous structure relying on an expanding library of cultural interpretation(s). Otherwise, you will get just what you got: literal transposition of words for their translated counterparts irrespective of proper syntax or sentence structure in that language.
(international use is on my mind heavily lately, as I wrap up the last of my system's bugs hoping to finally release a public ED profile for VA and EDDI (and bindED v2.0), where before my beta testers in countries that depict Pi as 3,14 as opposed to my countries depiction as 3.14 would have huge pauses between actions due to the loss of the decimal separator during init -- far beyond simple {DEC} conversions to {DECINV} -- and finally got it sorted after months of tinkering. Localization is so hard when you don't know 'both' languages with equal fluency; I got lucky since it's simple maths in my case)
Last edited: