New Italian translation

[GitGianluc]

New localisation rewritten from scratch, updated to v5.2beta10 (details in #13277)

[niksedk]

@bovirus: Can you take a look?

[bovirus]

@niksedk

I didn't understand why the user should reorder the string list.
Your translation program is useful for compare English and Italian.

I'm not agree about part of previous changes about parenthesis.

About to this new translation changing the order of strings make very complex to compare and confirm new transkation.

As I wrote in other post I'm not agree about the sentence regarding bad quality of current Italian translation.

I believe that first of all it's important to define if, where there are changes about strings for Italian language to confirm if I'm agree about the changes.

I believe that the string translation is more important about string order.

If the submitter is not agree about some current translation we can discuss about it.

Thanks.

[niksedk]

Please try to work on the same translation, thx :)

I've re-saved the current Italian translation using json-content-translator v1.7.0.

@GitGianluc: Please save your language file using the same version as well, and make a new PR against the current Italian language file. This way we can see the changes clearly and compare the translations more easily.

[GitGianluc]

@bovirus I’m sorry if my message bothered you: I had no intention of causing offence, but simply wanted to help make the translation sound more natural. I don’t want to get into technicalities that only a native Italian speaker would pick up on, but I think you’ll agree that Cut = «Taglio», Paste = «Impasto» (!!!) and Speech to text = «Discorso al testo» (!!) – just to give a few examples – aren’t exactly the best translations one could come up with…

@niksedk I’d also like to point out that I didn’t change the order of the lines intentionally: I used json-content-translator v1.6.0, but – as this was the first release for macOS – it may have had some issues. Anyway, to update the translation to the latest version (v5.2.0-beta15), I used version 1.7.0 of json-content-translator, as you suggested. A further suggestion for the future: might adding a column with the string’s unique ID be a solution?

I just saw your alternative translation and I think it’s excellent (speaking as a native Frenchman who lived in a small town in Savoy with a large Italian population); I fully agree with your approach.

@Need74 thank you so much for appreciating my work and for recognising the quality of a “human-aided” translation, which focuses on linguistic accuracy and the rendering of technical terminology. Thank you also very much for reordering the strings (I didn’t mean to mess them up: see above); I work on macOS, so I can’t use WinMerge :(

@niksedk to be honest, I thought that overwriting the translation already prepared by others would be offensive; that’s why I’ve proposed a completely alternative translation, which can coexist with the original one without offending anyone’s sensibilities and giving users the chance to choose. If, on the other hand, you’d prefer me to open a pull request against the current Italian language file… I’ll do so, but this seems a bit rude to me :)

[niksedk]

@GitGianluc @bovirus — thanks to both of you. Please read this as practical, not as a verdict on anyone's work.

I'd like Subtitle Edit to ship one Italian translation. The main reason is the users: someone opening Options → Choose UI language and finding "Italian" next to "Italian (alternative)" has no way of knowing what the difference is or which one to pick. That's a worse experience than either translation on its own. On top of that, two files means every new string in every beta has to be translated twice, and that's the part I can't sustain long-term. So this isn't about which translation is better — the project only has room for one, and I'd rather have the best of both in it.

To make sure we're all working from the same facts, I compared the two files key by key (3,249 strings exist in both):

• 1,942 strings (~64%) differ in wording, plus ~105 that differ only in punctuation style (... vs …, ' vs ’).
• The current file has 250 empty strings; the proposed one fills 232 of them.
• The current file has 7 strings where the {0} placeholders don't match English, and 10 where the _ menu accelerator is missing or misplaced. The proposed file has 1 of each.
• A few of the current strings are wrong rather than a matter of taste — e.g. Paste = "Impasto", Cut = "Taglio", and the whole Speech to text family rendered as "Sintesi vocale" (which is text-to-speech, the opposite), once as "Da voce a SMS".
• Some of the proposed changes are debatable in the other direction — e.g. "Database" → "Base di dati", "plugin" → "componenti aggiuntivi", "font" → "carattere". Italian software usage is split on those and I have no strong opinion.

One practical note, @GitGianluc: the file in this PR is not valid JSON — a comma is missing around line 933 and the same structural problem repeats through the file (a nested block closes before its siblings). CI hasn't run on the PR yet, but LanguageJsonFilesTests would fail on it, and SE wouldn't be able to load it as-is. It looks like an artifact of the reordering. Re-saving with json-content-translator v1.7.0 against the current Italian.json should sort it out.

So that nobody's work gets thrown away, I'd like to split this in two:

1. I've opened Italian: fill 232 empty strings and fix 31 broken ones #13718 as a start: it only fills the 232 empty strings and fixes the placeholder/accelerator/"Impasto" class of clear bugs, taking the wording from @GitGianluc's file and normalising the punctuation to the conventions already used in Italian.json. 263 lines, no preferences involved, translatedBy left untouched. @bovirus, could you have a look?
2. Then the wording preferences (Visualizza/Mostra, tasti rapidi/scorciatoie, .../…, and so on) as separate, smaller PRs that @bovirus and @GitGianluc can discuss line by line — rather than one 3,000-line diff where the real changes are invisible.

@bovirus, you've maintained this file for years and I'd like you to stay the reviewer of record on it. @GitGianluc, your suggestions are clearly useful and I'd like them in the main file rather than in a parallel one — proposing changes to an existing translation isn't rude here, it's how every other language file in SE has evolved.

Does that work for both of you?

[niksedk]

@GitGianluc — correction to my comment above, my mistake: I had fetched your file before your two latest commits, so the JSON complaint was about a stale revision. The current version parses cleanly, is at v5.2.0-beta15, cultureName is it-IT, and it has no empty strings left. Sorry for the noise.

I also re-ran the comparison against your updated file, and two things are worth noting:

• Your file now covers 43 strings that Italian.json doesn't have at all (they exist in English.json but were never added to the Italian file) — batch convert folder scanning, AI review hints, fix-common-errors log strings, and so on. That's a real gap your work closes, and I'd like those in.
• Nothing in your update conflicts with Italian: fill 232 empty strings and fix 31 broken ones #13718. Of the 263 strings that PR touches, the only divergences from your file are the punctuation normalisations (… → ..., ’ → '), which I did to keep Italian.json internally consistent rather than because I prefer one over the other.

Everything else in my previous comment still stands — I'd like one Italian file, built from the best of both, with @bovirus as the maintainer of record.

[GitGianluc]

@niksedk just to sum up the whole thing: is my latest commit correct in terms of JSON syntax (commas and curly brackets), structure (order of the strings), use of {#} placeholders and of _ character as a menu accelerator? This is certainly the most important aspect from my point of view.

To be honest, I’m not sure whether the two different approaches to translation are compatible, as I have tried to demonstrate with a few examples…