![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
12.12.2014 u 15:04, Sérgio Marques je napisao/la:
So why the hell someone decided to ignore what I and others told her?
Because you should be against something upfront. If it doesn't affect your
current workflow, why do you care?
I care because I still didn´t understood how the merge between branches
will be. So, for that reason, I´m still unsure if it will affect my work or
not.
As I understood it, you will have option to use it or not use it.
12.12.2014 u 16:00, Sérgio Marques je napisao/la:
Because you should be against something upfront. If it doesn't affect your
current workflow, why do you care?I care because I still didn´t understood how the merge between branches
will be. So, for that reason, I´m still unsure if it will affect my work or
not.As I understood it, you will have option to use it or not use it.
Oh, that was meant to be "Because you shouldn't..." 
Anyway, I think they will take your concerns into account when they decide to implement master branch on pootle.
Mihovil
Hi Stanislav, *,
the new workflow is a bit unclear for me. If I work only in branches, let's
say in 4.5, does it mean that
- changes from 4.5 branch will be ported back to master (if so, when?),
No. Nothing will be merged to master from the other branches. And
nothing will be merged from master to the other branches.
or
- changes in 4.5 branch will not affect the next 4.6 branch?
Yes. 4.2 translations don't affect 4.3 translations, 4.3 translations
don't affect 4.4 translations, and 4.4 translations won't affect 4.5
Btw, it's a bit ironic that the new workflow is introduced just after
conversion to .ui format is finally completed which should result in a
substantially lower translation workload for 4.5:)) I would tend to continue
with working on branches because master will bring only more (wasted)
work...
You can think of master as translation for 4.5 There's nothing special
about master.
regular code workflow:
______________________________________________ master
\ \ \ \
\ \ \ \__libreoffice-4-5
\ \ \__libreoffice-4-4
\ \__libreoffice-4-3
\__libreoffice-4-2
All branches were once "master", and then were split up to refine stuff.
Translations were special project, as basically there was no "in
between" updates. Translations did jump from 4-2 to 4-3, from 4-3 to
4-4 without any intermediate updates in between.
Master based workflow would mean that when libreoffice-4-5 is created,
the translations of master will be copied over and reused for that,
and master then would be ongoing for libreoffice-4-6
What is benefit for translators?
No rush needed when libreoffice-4-5 is about to be released, as you
have all the time preparing the translations on master. All you have
to translate when 4-5 is about to released is the changes that are
done very late in the release-process.
Having translations for master also allows to create daily builds with
the translations more easily, so you can check translations in the
daily builds more easily.
Drawback for translators:
If you have rather incomplete translations for 4-4, then you need to
do the changes in both 4-4 and in master. Or just ignore master and
only focus on 4-4 - but then of course you have to translate all the
stuff that changed in between when the 4-5 release is split-off.
translating both shouldn't be too much work, as you can just reuse the
proposals of the translation-memory.
And all those *##* who keep ranting about the changing caps and
similar: It has been made pretty clear already that any such change
would be handled automatically with no need for retranslating. Shut
the f* up/write your stuff in other threads if you don't want to
participate in the current topic.
I'm puzzled where the perception comes from that on master you
suddenly have thousands of additional strings that you wouldn't have
to translate in the current process as well.
To ask some of the on-topic questions:
* why all languages, not just some
→ less work. It's lot easier to just process all languages at once
and don't need to think about picking individual languages.
→ that being said: You're not forced to use it. If you don't
translate on master, then you'll just have to translate all at once
shortly before release (like it's the case currently).
* master translations will only be used for the daily/snapshot builds,
not for releases. No migration from master to 4-4 or 4-3 will happen.
If you want to have the change in the release-branches, you need to
update the 4-4/4-3 translation yourself.
* master translations will be copied to 4-5 when it is due, and then
4-5 will be used for the 4.5.x release builds, and master will become
the ongoing translation for 4.6
* how frequent will there be updates
→ no more than once a moth
Translations/dialogs/etc don't change so frequently, so there won't
be changes all over the place.
* what if I don't want to use master
→ then make sure you don't actually do stuff in master, as then it
will be overriden when 4-5 is branched off
→ for those languages who chose not to make use of master, shortly
before the branch-off of 4-5 the translations of 4-4 will be copied to
master (override current master translation) and updated against
templates.
In other words: If you don't want to use master: Don't use master.
Changes you do on master will be overridden when you request copying
from 4-4. So either do any merges yourself, or don't complain
afterwards.
ciao
Christian
12.12.2014. u 21:42, Christian Lohmaier je napisao/la:
In other words: If you don't want to use master: Don't use master. Changes you do on master will be overridden when you request copying from 4-4. So either do any merges yourself, or don't complain afterwards. ciao Christian
Since I didn't understand this part, can you please dumb it down for me, please.
1. I work on 4.4 and not on master - what happens when 4.5 becomes stable?
2. I work on master and not 4.4 - what happens when 4.5 becomes stable?
3. I make changes to both master and 4.4 - what happens when 4.5 becomes stable?
Mihovil
Sgrìobh Christian Lohmaier na leanas 12/12/2014 aig 20:42:
And all those *##* who keep ranting about the changing caps and
similar: It has been made pretty clear already that any such change
would be handled automatically with no need for retranslating. Shut
the f* up/write your stuff in other threads if you don't want to
participate in the current topic.
Errr... please calm down? Given that this seems to have grown out of the issue around precisely that, you can't blame people for thinking these are connected. I am certainly one of those who participated in the original complaint about the way those were handled and as best as I can tell, this seemed to be (Sophie's) propsed solution. Suddently it isn't. So fine, maybe this is just a topic that coincides with that other debate and has nothing at all to do with the solution to the nonsense around cosmetic changes to en-US but that *certainly* did not come across clearly in that case.
In other words: If you don't want to use master: Don't use master.
Changes you do on master will be overridden when you request copying
from 4-4. So either do any merges yourself, or don't complain
afterwards.
How are we going to clearly explain this to all the translators on Pootle within the Pootle interface because not all of them are on this list? Never mind the issue of how many of them understand this discussion.
Michael
As a localiser, I find it worrying that “localisers” think that using
correct capitalisation or punctuation marks “nonsense cosmetics”, really
scary. I can understand people being annoying about changes in source
that does not affect the final translation, but the apparent total
disregard of those “cosmetics” (they are not) is not something I except
from people whose job is to adapt software interface to the proper rules
and costumes of there languages and should generally know better.
Regards,
Khaled
True but what gets my goat is that many of these are *totally* arbitrary. Case in point, sentence case vs title case. Unfortunately this debate comes at a time when Microsoft has gone *exactly* 180° the other way (going forward) compared to LibreOffice. So that makes it arbitrary.
That's even without considering the fact that Nagari, CJK and so on don't even have case...
If Gaelic has to implement a change in convention then I implement that without affecting 100 locales. Would be nice if the source for projects like LO worked the same way because whether English uses formatted or unformatted quotes or sentence vs title case does not affect how the other 100 locales localizer. That's not disregard for conventions. It's disregard to the time I donate as a localizer.
Michael
Sgrìobh Khaled Hosny na leanas 13/12/2014 aig 00:22:
Those changes, while possibly worthwhile from en_US perspective, are not related to what localised interface looks like. Since version 2 the workload in ui strings might easily constitute +100% of initial 25k. Did the ui change that much? No.
Yury
the nonsense around cosmetic changes to en-US
As a localiser, I find it worrying that “localisers” think that using
correct capitalisation or punctuation marks “nonsense cosmetics”, really
scary. I can understand people being annoying about changes in source
...
Not so feasible, I think.
Work based on another translation would very likely mean missing important nuances. Ironically, this was the case with English (!) in times of OO 2.0, when it was somewhat more instructive to look into German strings (originating from StarOffice) for the precise meaning of some financial maths terms.
Yury
Earlier there was a suggestion of creating some
sort of buffer-language between English (US) and
all the other languages.Is there a language that doesn't have so many
'little' changes that affect so much? One that
gets all the translations done really fast?
Perhaps Spanish, Portugese (Br), German, French,
Italian?If so might that be a better language to use as
the base-line to translate from?
...
I would really like to see what kind spelling rules in en_US supports this:
https://translations.documentfoundation.org/fr/libo_ui/translate/sc/uiconfig/scalc/ui.po#unit=79290454
Read filter criteria from --> Read Filter Criteria From
If this isn't purely cosmetical change, I don't know what it is.
FR didn't translate their SC directory so you can easily check there, at least 70% of Calc changes are first letter capitalisation or : on end of string.
Mihovil
13.12.2014. u 1:22, Khaled Hosny je napisao/la:
Hi
Earlier there was a suggestion of creating some sort of buffer-language
between English (US) and all the other languages.
Is there a language that doesn't have so many 'little' changes that affect
so much? One that gets all the translations done really fast? Perhaps
Spanish, Portugese (Br), German, French, Italian?
If so might that be a better language to use as the base-line to translate
from?
Regards from
Tom
Me too! But the fact is that you are a typographer, and the other
don't care about things such as microtypography, which IMO is
essential in UX.
Also, childish bickering (a consequence of ignorance) is showing up in
this list too much... which is sad, because the bulk of necessary
changes is already done anyway.
As a localiser, I find it worrying that “localisers” think that using
correct capitalisation or punctuation marks “nonsense cosmetics”, really scary.
Changes made in one dialect of one language should neither affect, nor
effect changes in other dialects of the same language, much less other
languages.
from people whose job is to adapt software interface to the proper rules
and costumes of there languages and should generally know better.
In professionally run l10n & i18n projects, a change in one dialect
won't affect any other dialects, or languages.
What happens here, is any time a change is made for what is construed as
en_US, _every_ project has to recheck their entire translation, even if
the only change was presentation markup.
jonathon
* English - detected
* English
* English
<javascript:void(0);>
Not a language, but a working assumption that all supported languages
are translations of the strings from the source UI.
IOW, you have an en_US team, alongside an en_UK team, alongside an af_ZA
team, alongside a de_CH team, etc.
jonathon
* English - detected
* English
* English
<javascript:void(0);>
Huh? English (US) is the “source” language, changes to it should, by
default, be reflected in all other localisation, unless those changes
are not applicable to the target language, but this is the exception not
the rule.
Regards,
Khaled
I would really like to see what kind spelling rules in en_US supports this:
https://translations.documentfoundation.org/fr/libo_ui/translate/sc/uiconfig/scalc/ui.po#unit=79290454
Read filter criteria from --> Read Filter Criteria From
So? Report a bug about the bad translation, how is that relevant to the
fact that people think that using proper quotation marks, for example,
is a fancy, useless thing that they should not be bothered about?
If this isn't purely cosmetical change, I don't know what it is.
FR didn't translate their SC directory so you can easily check there, at
least 70% of Calc changes are first letter capitalisation or : on end of
string.
So, the original strings were badly written, should they remain like
that for ever? And inserting a colon where appropriate is not language
specific (unless your language does not use punctuation) so all
translations must be changed to reflect this change in source strings.
Regards,
Khaled
Khaled,
That is precisely the point. Most locales are more specific with regards to things like sentence case vs camel case. English just changes its approach to this issue depending on the phase of the moon and the number of ripe mangos in Florida. In German, you can't just decide that suddently you're going to change the way caps work, German rules are quite clear on the whole about what you can and cannot capitalize and that's not a stylistic choice but rules that depend on grammatical categories. Nouns, basically, can be capitalized. If it's not a noun, forget it. No amount of stylistic filing in en-US will change German spelling rules.
Same goes for Gaelic. Or indeed, Chinese, Hindi, Urdu, Marathi, Georgian, Nepali etc which don't even have upper and lowercase characters/glyphs.
It seems very odd to think that just because en-US implements a stylistic change, suddenly the rest of the planet has to follow suit. Of *course* if there is a typo in en-US then it needs fixing but if I've already localized the string then, unless the typo was sense-changing, I don't care because I won't have copied the typo, will I? I make my own typos 
Michael
Sgrìobh Khaled Hosny na leanas 13/12/2014 aig 21:45:
Exactly, you wrapped it nicely.
In croatian it's similiar, only names (people, brands, companies...) and some nouns can have capital letter, rest can't.
I'm not really sure if english doesn't have any caps rules or people just ignore them for "style" sake.
happy I really don't care.
Point is, don't transfer meaningless work onto others, make your changes only in en_US without marking all of our strings "fuzzy" and we will all stay happy.
I know everyone is sick and tired of mailing lists rant about this, but this actually isn't first time this happened.
There wasn't much complaining about ~ to _ and that brought shitload of unneeded fuzzy strings, but we all survived.
Let's not have this again.
Mihovil
13.12.2014. u 23:08, Michael Bauer je napisao/la:
Treating en_US, en_DE, en_UK, or any variant thereof as the "source"
language is, at best, translation mismanagement.
The more fundamental error is assuming that what is in source is
consistently en_US, or any other en_* variant.
jonathon
So, the original strings were badly written,
That is just one of myriad reasons why treating en_US, en_DE, en_UK, or
any variant thereof as the "source" language is, at best, translation
mismanagement.
specific (unless your language does not use punctuation)
There are dialects of English in which neither majuscles nor punctuation
are known.
To address Mihovil's question, English has never met a grammatical rule
that it has felt obliged to adhere to.
jonathon