19 replies to this topic

[nautilus7]

Currently titles in menus and various screens are written in all possible ways. Some are written in camel case style and some are written in all lower case. I would like your opinion so we can decide to a style that will be used from now on in new titles. I will try to find and correct all existing titles as well.

 

Camel Case.

Examples:

 

Main Menu

Audio selection

InfoBar

HotKey

Subtitle Settings

Latest Commits

 

First letter in upper case and all others in lower case.

Examples:

 

Main menu

Audio seletion

Infobar

Hotkey

Subtitle settings

Latest commits

 

 

So, what style do you prefer? Please vote!!!

Edited by nautilus7, 7 February 2018 - 23:42.

[MiLo]

I think it's language dependent, so there's little point voting on it.

Titles in English are usually in Camel Case, while titles in Dutch generally use lower case. In German, all nouns must be written with a capital.

But something like "InfoBar" and "HotKey" is plain wrong in any language, we shouldn't do that.

It's perfectly okay therefore to change the casing in translation.

Edited by MiLo, 8 February 2018 - 09:15.

[nautilus7]

I am not concerned about translations. Translators can do whatever they feel it suites them (for example in Greek it should be all lowercase, which is not...).

 

 

I mean English strings inside the (python) code. Now it is a mixed bag. There is InfoBar, infoBar, HotKey Setup, Hotkey Setup, Software update... and all these are just in one file. I believe it doesn't harm to vote.

I am in the process of writing a skin currently, so I have to check all screens. Therefore, it's easy for me to find and correct all those strings that don't conform to the style we want, as soon as we decide which style we like.

Edited by nautilus7, 8 February 2018 - 11:12.

[Robinson]

Good initiative!

[nautilus7]

Thanks!

 

Guys just to be clear... We vote for the English titles style!!!

Edited by nautilus7, 8 February 2018 - 11:27.

[WanWizard]

Agreed in code it should be in correct English. 

 

Unfortunately there aren't any coding standards, and de codebase is 10+ years of "organic coding" and lack of proper design. Leading to the current bowl of spaghetti.

 

Ideally, the current codebase should be abandoned, a new architecture and design should be made, more professional, and taking into account the current hardware capabilities, and a new and better platform should be build. But that is a huge undertaking, for which you need people and commitment, both not really available at the moment.

[Erik Slagter]

We have had this discussion before. Short recap:

 

- when anything, at all, changes in the English texts, all translations must be adapted to the new "identifier", a lot of work for the translators

- correct English is the same as Dutch in this respect, capitals should only be used in the word first for the line and names.

- it's some "common" use in newspapers (I think mainly American) to use "random" upper cased words, which is clearly wrong, but apparently accepted

 

I don't think we should adorse this (incorrect) use and correct all English strings. Capitals only for names and first letter of the sentence, please!

[Pr2]

We have had this discussion before. Short recap:

 

- when anything, at all, changes in the English texts, all translations must be adapted to the new "identifier", a lot of work for the translators

...

 

I don't think we should adorse this (incorrect) use and correct all English strings. Capitals only for names and first letter of the sentence, please!

 

Hi,

 

If the original strings are changed it would be nice if all the .po files are also updated at the same time (for exemple with a sed command on every .po files) so no more overhead work for the translators. But if many already translated strings are changed without automatically change it in the .po files, it will be really boring for translators to redo everything.

 

Pr2

[Rob van der Does]

- when anything, at all, changes in the English texts, all translations must be adapted to the new "identifier", a lot of work for the translators

Not correct. When using a current version of POEDIT it already suggests the most likely translation, if it can find an (almost) similar in the current po-file (which will always be the case in this kind of language corrections). This means the translator has hardly anything to do at all.

And just as coding is an ongoing hobby, so is translating and skinning.

[Rob van der Does]

 

We have had this discussion before. Short recap:

 

- when anything, at all, changes in the English texts, all translations must be adapted to the new "identifier", a lot of work for the translators

...

 

I don't think we should adorse this (incorrect) use and correct all English strings. Capitals only for names and first letter of the sentence, please!

 

Hi,

 

If the original strings are changed it would be nice if all the .po files are also updated at the same time (for exemple with a sed command on every .po files) so no more overhead work for the translators. But if many already translated strings are changed without automatically change it in the .po files, it will be really boring for translators to redo everything.

 

Pr2

 

 

I'm one of the translators for OpenViX and I'm used to see every po-file updated on every single build. This is indeed very easy for translators, and I would have though that to be standard practice. Reading your statement I guess this is not the case for PLi, correct?

If so, I would suggest PLi to adopt that system as well. It is really inviting for translators to keep the translations up-to-date.

 

 

- when anything, at all, changes in the English texts, all translations must be adapted to the new "identifier", a lot of work for the translators

Not correct. When using a current version of POEDIT it already suggests the most likely translation, if it can find an (almost) similar in the current po-file (which will always be the case in this kind of language corrections). This means the translator has hardly anything to do at all.

And just as coding is an ongoing hobby, so is translating and skinning.

Having said that: even if translations would require more work, that surely can't be a reason to stop development?

[Pr2]

 

- when anything, at all, changes in the English texts, all translations must be adapted to the new "identifier", a lot of work for the translators

Not correct. When using a current version of POEDIT it already suggests the most likely translation, if it can find an (almost) similar in the current po-file (which will always be the case in this kind of language corrections). This means the translator has hardly anything to do at all.

And just as coding is an ongoing hobby, so is translating and skinning.

 

 

Hi,

 

Do you really trust at 100% the proposed translation of PoEdit, and quid if you edit your translation later on to improve it? Won't the POEdit propose then both suggestion?

So yes if many strings are changed this will anyway creates lots of works for translators if they need to review everything again and again even if POEdit makes suggestion they all need to be reviewed individually.

 

And no when string are changed in the OpenPLi "core" they are not changed automatically in the po files, and the po files proposed in the github are not often updated. Only the "translated ones" are updated the one that don't have active translator can remains quite old for a very long time.

 

So yes translation is a hobby but hobby doesn't means that you have to redo always the same things.

 

Pr2

[nautilus7]

Yes, while poedit suggests the closest translation as Rob said, the translator will have to review the strings one by one. But in most cases the translator will not be needed to type anything.

 

Anyway, what I originally suggested was to change/fix the screen titles and the menus. This in not very much work and not all strings need fixing. At a later stage we can go on with other strings, inside each screen.

Edited by nautilus7, 10 February 2018 - 02:10.

[Rob van der Does]

Of course one has to check the translations suggested by POEDIT; that's the reason they're marked as such by POEDIT. The correctness of the suggestion depends very much on the kind of change the text has undergone.

But in many (even in most) cases the translator only has to make minor corrections.

 

 

Anyway: caring for translators should never be a reason to stop development; the same applies to skinners.

Edited by Rob van der Does, 10 February 2018 - 05:26.

[Persian Prince]

Just for your information "Persian" is a hard language to understand and harder for translations so you can't use automatic translations just like that

[Rob van der Does]

I pity you

 

But just for my information: I thought "Persia" and hence "Persian" doesn't exist any more (since 1979). Can you clarify that for me please?

[Pr2]

Hi,

 

Of course translators are never a brake to development anyway there is a sentence that says: "A good IT guy is a lazy one", meaning that he tries to ease his life, so since we are in the IT world if a string is change it is easy to perform a 'sed' to replace the changed strings in every .po files.

 

Pr2

[Rob van der Does]

As I said: this process has been automated for years in OpenViX; surely PLi could do the same thing?

[WanWizard]

It is, like so many things, on the todo list. But more ambitions than hands and time.

 

What does OpenVIX use as a toolset?

[Persian Prince]

I pity you
 
But just for my information: I thought "Persia" and hence "Persian" doesn't exist any more (since 1979). Can you clarify that for me please?

Our country is "Iran" and we don't call it "Persia" but our language is "Persian" or "Farsi" both are same names, So many people think Persian is Arabic which is 100% wrong, We don't speak ancient Persian which stands for "530 BC" actually it's modern Persian

[Rob van der Does]

Ah, OK, Farsi is the term I know indeed.