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…

[niksedk]

@GitGianluc — first the direct answer to your question, because you asked it plainly and you deserve a plain answer: yes, your latest commit is technically correct. I checked it against English.json at beta16:

• Valid JSON — it parses and loads.
• Key order matches English.json exactly, both top level and nested. The reordering problem from the earlier revision is gone.
• No empty strings at all (the current Italian.json still has 18).
• Placeholders: one slip, main.pastedXOfYLinesOverSelectedLines — and main.xLinesMerged has X righe unite where English has {0} lines merged, but that one you inherited from Italian.json, so it's on both of us.
• Menu accelerators: clean, apart from general.done, which is missing the _ in the current file too.

So the craftsmanship isn't in question, and nothing below is a verdict on the quality of your work. It's genuinely good, and a lot of it.

Why I'm closing this PR anyway: Subtitle Edit should ship one Italian file.

Picture the user who opens Options and sees "Italian" and "Italian (alternative)" in the list. They have no way of knowing what separates them — no preview, no explanation, nothing but a word in parentheses. They pick one at random, and half of them get the file we consider second-best. Two files don't give users a choice; they give them a coin flip and a small doubt that follows them around the program. One good file is worth more to them than two competing ones.

There's a maintenance side too: every beta adds strings, and two files means every one of them gets translated twice, forever, or one file quietly rots and users can't tell which. That's the part I can't sustain.

On the thing I think is really holding this up — you wrote that overwriting a translation someone else prepared felt offensive to you, and that proposing changes to it seemed a bit rude. I'd like to push back on that gently, because it's the one point where I think open source works differently than you expect.

Nobody owns a file here, not even me. Italian.json was written by a group over many years, and the way it got good is that people kept proposing changes to each other's work. A pull request isn't a takeover — it's a proposal, out in the open, that others can argue with line by line. Disagreement in review isn't a fight, it's the actual mechanism: bovirus pushing back on "Base di dati" and you pushing back on "Impasto" is the process working, not failing. And nothing gets lost — git keeps every version and every author's name, so improving a line doesn't erase whoever wrote it first. Your name is already in the file's translatedBy line, and it stays there.

A parallel file avoids that conversation. But the conversation is where the good translation comes from.

So here's where your work goes, concretely:

1. Italian: fill 232 empty strings and fix 31 broken ones #13718 is merged — 232 empty strings filled and 31 broken ones fixed, taking the wording from your file, with you credited.
2. Your file still has 116 strings that Italian.json doesn't have at all — batch convert folder scanning, AI review, fix-common-errors logging, the newer translate settings. Those are pure gain with no wording dispute attached. A PR with just those would be very welcome and I'd merge it quickly.
3. After that, the wording preferences (Visualizza/Mostra, ... vs …, "font" vs "carattere", and the rest) as small themed PRs that you and @bovirus can settle one at a time. Where a change is clearly a correction, it goes in. Where it's taste, you two talk it out — and a maintainer who's kept a translation alive for years has earned a real say in that, just as a native speaker who spots "Impasto" for Paste has earned one.

Thank you both. Closing this one because of the one-file rule, not because of the work in it — and the work in it is already landing in the main file, piece by piece.

[GitGianluc]

@niksedk I fully understand the technical and practical reasons behind your decision and accept them without reservation. Let me just say a few words, though.

On the thing I think is really holding this up — you wrote that overwriting a translation someone else prepared felt offensive to you, and that proposing changes to it seemed a bit rude. I'd like to push back on that gently, because it's the one point where I think open source works differently than you expect. […]
A parallel file avoids that conversation. But the conversation is where the good translation comes from.

I feel a bit disheartened by this comment, which depicts me as a presumptuous guy, unwilling to engage in discussion and unfamiliar with the philosophy of open source; nothing could be further from the spirit of my initiative and my twenty years’ experience as a translator of school (!) textbooks and contributor to open-source projects, not necessarily hosted on GitHub… I’m sorry you’ve come to this conclusion: I did not propose a new translation because I thought I was taking part in a contest of skill, but simply because I believed it was worth sharing the effort.

In conclusion, I’m sorry to have caused all this fuss without meaning to. I would like to express my deep respect for you and for the excellent work you are doing: I wish you all the best for the future and, with no hard feelings, I will try to contribute as best I can by following the guidelines you have set out.

[niksedk]

@GitGianluc: thx for your feedback, and sorry, that paragraph landed badly. I use AI to help draft some of my longer replies, and this one came out as a lecture that was never intended — nothing in this thread suggests you're presumptuous or new to open source, quite the opposite. My apologies.

No hard feelings here either — your work is appreciated, and PRs with new strings will be very welcome.