Closed Bug 305892 Opened 14 years ago Closed 10 years ago

[sr] Seamonkey Serbian translation - general discussion and planning bug

Categories

(Mozilla Localizations :: sr / Serbian, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: nikolaprevod, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728

the product you want to localize: Mozilla Application suite
the language + country code: Serbian latin and Cyrilic + SR (scc/srp* sr Serbian)

I would thank any suggestion for start.

Reproducible: Always
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 283456
I would like to restart this bug, since bug was about Mozilla Application suite,
and now SeaMonkey internet suite and not Firefox and Thunderbird.
We are seriously organizing now and SeaMonkey Serbian Cyrilic and Latin translation is related to 2.0+ version of SeaMonkey.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Version: unspecified → SeaMonkey 2.0 Branch
We're not gonna reopen this bug. Instead, we're gonna start new tracking bug, and few more if needed.
Why? It is only one we have. and oldest as I see. Maybe we could stick to it an just move on? Anyway, We will translate Seamonkey from the bottom to the top, not using Firefox translations, etc. So this bug About Seamonkey have nothing to do with Firefox & Thunderbird. please mark it confirmed, anyway.
(In reply to comment #5)
> Why? It is only one we have. and oldest as I see. Maybe we could stick to it an just move on?

I'll make a new bug, and will name it tracking bug. This bug is pretty old. Don't worry, I'll do that in a few.

>  Anyway, We will translate Seamonkey from the bottom to the top,
> not using Firefox translations, etc. 

We're not gonna depend on Firefox translation, but I'll try to use as much as I can because I see no need to translate same things twice.
I am fully against any dependencies on Firefox translation and using it in Seamonkey translation.
We will not use Firefox dependencies.

I see need to be able to make translation as a project for Seamonkey that is compleatly distinguishable form Mozilla Firefox.

Seamonkey-project also does not seems to be supported by Mozilla for a very long time and I do not want to translata Seamonkey as dependable on Firefox.
We are not going to depend on Firefox translation at all.

As I said in introductory conversations, 
I dont see why being this bug old is important at all. We have it. Is the problem I started is long ago? Please confirm this bug.
Talking imperative will take you nowhere. Please switch to 

https://bugzilla.mozilla.org/show_bug.cgi?id=534855
Also will not take you. Please confirm this bug as a start.
This is a duplicate of the SeaMonkey Serbian tracking bug in bug 534855 and you need to coordinate any efforts with Milos there.

Once you have a state in the sr Mercurial repository that is ready to at least generate some kind of builds from, please file a bug in the SeaMonkey Build Config component to get sr added to all-locales (on trunk and/or branch, as needed by what you are working on).
And once you have a state there that you consider ready and fills the requirements, please opt in to be included in the next release.
Assignee: general → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 534855
Note that the script for localizing Mozilla products is Cyrillic.  There is currently no provision for Latin.  You can, if you want, procure the Latin translation if you want to, but you will have to do it yourself.

I also don't understand why the SeaMonkey translation should be independent from Firefox where they do share the translation strings.  It seems like a waste of effort.  What's the rationale?

I too am in favor of keeping this as "the" place to discuss the issue, since a lot of context is already here.
Hello Filip, 
Yes, Script for thanslation truely is cyrillic by default: Take a look at my notes published on: http://www.mozilla-srbija.org/forum/prevod-mozilla-proizvoda/seamonkey-2-0-x-prevod/ 

I think that translation for Seamonkey and Firefox should not be the same by default.They are not the same applications, not the same people are using it and not the same people are translating.

I need to be sure that every translation string in Seamonkey is looked at, put to thinking, discussed about and approved by us.
I see absolutely no need for rush and copy/pasting anything.
If someone loves to see FF translation for reference, then it could be used to take a look at, not copy/pasting without discussion. That is my rationale.

Bug is selected as Duplicate by Robert Kaiser, 
even it is much older then Yesterday`s tracking bug, and I do not know what I need to do about it maybe selecting it not a duplicate of newer bug made by Milos? Milos was insisting in making new tracking bug (so It would be one that he started, I suppose)
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #12)
> I think that translation for Seamonkey and Firefox should not be the same by
> default.They are not the same applications, not the same people are using it
> and not the same people are translating.
> 
> I need to be sure that every translation string in Seamonkey is looked at, put
> to thinking, discussed about and approved by us.
> I see absolutely no need for rush and copy/pasting anything.
> If someone loves to see FF translation for reference, then it could be used to
> take a look at, not copy/pasting without discussion. That is my rationale.

Maybe I'm not understanding something right.  Why would you want the same string X to have different translations in SeaMonkey and in Firefox?  Isn't it better to have an unified translation across products, for consistency, quality and for engineering effort economy's sake?

That the user base and the translators are physically different people is a red herring, not a rationale: 1+1=2 regardless of whether I compute it, or you compute it.  In a similar vein, a string X, appearing in the same context in two different instances, should have the same translation.  If you think it should not, I'm open to reading a counter-example from you.

I understand that you'd like to vet your own translations, but if you do so, why are you then missing the opportunity to have Firefox and Thunderbird benefit from it as well?  It's not a question of rushing and copy/pasting, but the question of how efficiently we use the hands that we have available.  In reality there are tools that can help you not in copy/pasting, but rather in translation maintenance -- I am open to explaining the details if you ask.

It's relatively easy to make one single release, but maintaining a translation is a lot of pain (translating Mozilla tools is quite *unlike* translating other open source software, much to my dismay) and if we fragment the translation effort we only add to that burden.  

I don't want to stand in your way, but I also feel very strongly that you should first make a bona-fide effort to unify the translations, before rolling your own.
Any localization for SeaMonkey that does not base on the toolkit and application strings shared by all Mozilla applications, including Firefox, will not be accepted.

For Cyrillic Serbian, bug is the tracker and there is no use in having a bug in the SeaMonkey product, it belongs in the localizations product.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 534855
(In reply to comment #13)
> (In reply to comment #12)
> > take a look at, not copy/pasting without discussion. That is my rationale.
> 
> Maybe I'm not understanding something right.  Why would you want the same
> string X to have different translations in SeaMonkey and in Firefox?  Isn't it
> better to have an unified translation across products, for consistency, quality
> and for engineering effort economy's sake?
It seems reasonable what you say.
But, is it reasonable to think that people that were translating Firefox or Thunderbird, would want to accept our changes in Their translations?
If we agree to translate some strings differently, how that will affect other products.
And where is there freedom of choosing our solutions, how to manage that?

> That the user base and the translators are physically different people is a red
> herring, not a rationale: 1+1=2 regardless of whether I compute it, or you
It seems that Milos already disagree without explaining it.
I mostly see already that 1+1=1 to Milos. (?)
I explained (in maybe harsh way) my uncertainty about not being able to make quality translations, without freedom of actually translating and not copying and adding different strings. But maybe you could explain further down in this post.

> compute it.  In a similar vein, a string X, appearing in the same context in
> two different instances, should have the same translation.  If you think it
> should not, I'm open to reading a counter-example from you.
I choosed not to use localized FF, TB (I use SM mostly anyway) to be able to provide fresh perspective to translation and all strings.
If I already use semi-translated strings, I might not be able to achieve such fresh perspective in translations.
And Translating is not actually exact science. Ypu can say the same thing in many different ways. Maybe we get to some string that we do not like and want to use compleatly different word or string for it. 
Or to simply be different from FF, the same way Seamonkey application is 
different in its concept to the others? Is that hard to understand.
Seamonkey is not Firefox, it is not Thunderbird, it is not Sunbird.
It is Seamonkey, different beast with its different people using it.
Thus, translation to same strings might be different.

> I understand that you'd like to vet your own translations, but if you do so,
Not vet I think. It is collaborative effort. But it is needed to colaborate
and work and talk about every string and to have best possible solution.
(And not necessarily ¨mainstream¨ one, etc.
 
> why are you then missing the opportunity to have Firefox and Thunderbird
> benefit from it as well?  It's not a question of rushing and copy/pasting, but
> the question of how efficiently we use the hands that we have available.  In
Well, if translations differs in some or many aspects, maybe that will 
only add to quality of translation, so FF/TB people could have more to choose from.
I am also much more considered to quality then to rush into fast releasing.
We can get more people to translate during time, but I See your have a point considering
manpower available. I think I increased Seamonkey usage over time with advocatimg Seamonkey

> reality there are tools that can help you not in copy/pasting, but rather in
> translation maintenance -- I am open to explaining the details if you ask.
That would be great about those tools, I guess that would be much more meaningful then mentioning only mercurial pull , even that I previosly I already told Milos that I already did that, weeks ago.
> 
> It's relatively easy to make one single release, but maintaining a translation
> is a lot of pain (translating Mozilla tools is quite *unlike* translating other
> open source software, much to my dismay) and if we fragment the translation
> effort we only add to that burden.  
I were not exactly getting involved before with Mozilla-based product translation processes so I am taking your word on it.
As I heard from some git and Mercurial descriptions, it is powerfull versioning system that allow many things over older ways of doing things. (Only one commiter etc)
Do you think it could be used in a way that could provide that translations flexibility that I have in mind, to be free to make our own translation, 
without need to be the same as ff/tb?
> I don't want to stand in your way, but I also feel very strongly that you
> should first make a bona-fide effort to unify the translations, before rolling
> your own.
I think that effort to include uncontrolled strings from another project to SeaMonkey translation, just because they ¨are there¨ will not result in rising quality of translation.
If you suggest to actually DO copying all matching strings (And I am not sure how many of them are actually transferable in such a fashion and stay in same context and serve purpose)  and after that browse through them and fill in the blanks specific to seamonkey and review and change those we think should not stay the same, that brings me to start with question, how that will affect people that translated those strings we are changing i ff/tb and what would users say if in next ff/tb release they face changed and unfamiliar changed strings?
That is reason why we should do a fresh start, make our own decisions, do our job the best we can from English to Serbian, and THEN see what differences we have between them.

If people that translated ff/tb do not except some or many of our changed strings and solutions, they can stay with their solutions and we could stay with ours.
I do not want that Firefox/Thunderbird should be forced use the same strings we do. And I do not want Seamonkey translation to be forced to use strings I potentially do not like from FF/Tb aether.

I am also thinking.. If Seamonkey is community product (And not Mozilla company product, but using only its Infrastructure)
Why it is so important and ¨must have¨ to have same strings on Mozilla-based applications?

Seamonkey at a present state surely share much program code with Firefox or even Thunderbird. But it is clearly separate product line from those two.

Did Mozilla company actually is saying that Seamonkey-project is Mozilla`s project and Mozilla-controlled now?
So it needs to be Mozilla-translation-centric?

Why Seamonkey is ¨Mozilla application¨. Isn`t Seamonkey a project, not tight with Firefox and Thunderbird Mozilla`s decisions about it?

If we choose to use Seamonkey and not to use Firefox because we like Seamonkey better and do our things every Day in different way, why should we be deprived from right to actually choose our own thanslation strings?
Is it that Seamonkey is turned in company-dependent product with no freedom to choose or it is just some technical question of being hard to maintain separate translations for Seamonkey?

I just say, translation will be based on toolkit But translated strings could be different between aplications, because they are different applications. And we like Seamonkey in its different way.

As I understand now, toolkit is such shared component that presents application for itself and toolkit itself has its own translation and ¨products¨ build around it, just add additional strings for translation?

So at the end as I understand, It is question of translating toolkit+extra strings for Seamonkey-project? 
If that is so, lets first review strings that falls under ¨toolkit¨ category, send our suggestions and/or changes to translators from other teams to approve/disprove 
After that is done, we can then start from scratch with the rest of Seamonkey translation,
having ALL freedom of choosing how to translate, with no Firefox/Tb inheritance imposed? (consulted of course but with no obligation to use the same strings in rest of it)
Agreed Filip?
This bug actually turned itself into **general discussion and planning bug** for Seamonkey translation in Serbian. I also think discussion here is valuable,  
 without trying to duplicate Tracking bug. 
Some of my messages got Deleted from project forum By Milos  It included huge translations guidance document from other projects for new translators, followed by Milos leadership criticism, and both got wiped out.
And we have nowhere to collaborate freely but here. So I am restarting this bug because we need it to coordinate our work and choose whatever course of action we will do. 

I again say that Milos made bad start and collaborating with him will impose vast impact on project but that does not mean that we couldn`t use this bug to do our work. Please do not close it till we figure out what to do next?

I am not sure how to change this bug from not targeting Seamonkey product but to target localization product instead? May changing it to ¨Mozilla localizations¨ Instead of Seamonkey product, do the trick?
Status: RESOLVED → UNCONFIRMED
Component: General → sr / Serbian
Product: SeaMonkey → Mozilla Localizations
Resolution: DUPLICATE → ---
Version: SeaMonkey 2.0 Branch → unspecified
Alias: [sr]SM-discuss
Summary: Want to make effort to localize Mozilla product line on Serbian Latin and Cyrilic → [sr] Seamonkey Serbian translation - general discussion and planning bug
Alias: [sr]SM-discuss → SM-discuss
Summary: [sr] Seamonkey Serbian translation - general discussion and planning bug → Seamonkey Serbian translation - general discussion and planning bug
Alias: SM-discuss
Summary: Seamonkey Serbian translation - general discussion and planning bug → [sr] Seamonkey Serbian translation - general discussion and planning bug
(In reply to comment #15)
> (In reply to comment #13)
> > (In reply to comment #12)
> > Maybe I'm not understanding something right.  Why would you want the same
> > string X to have different translations in SeaMonkey and in Firefox?  Isn't it
> > better to have an unified translation across products, for consistency, quality
> > and for engineering effort economy's sake?
> It seems reasonable what you say.
> But, is it reasonable to think that people that were translating Firefox or
> Thunderbird, would want to accept our changes in Their translations?

Have you tried asking them?  I bet you didn't, because I'm those people, and I don't remember you asking. :)

> And where is there freedom of choosing our solutions, how to manage that?

The freedom is in that you can always make your own fork of the Mozilla code, and distribute it.  It has been done before.

> I choosed not to use localized FF, TB (I use SM mostly anyway) to be able to
> provide fresh perspective to translation and all strings. [...]
> Seamonkey is not Firefox, it is not Thunderbird, it is not Sunbird.
> It is Seamonkey, different beast with its different people using it.
> Thus, translation to same strings might be different.

You spent a lot of effort to describe your position, and I respect that.

But I do not believe your approach has merit, because experience has shown that approaches like yours don't last.

Still, what I think is irrelevant because my standpoint is not a bottleneck --- Mozilla people simply won't let you do what you intend (see Comment 14), because the more disorder there is in a translation team, the more Mozilla ends up using their resources (equipment, engineer-hours etc), and doesn't get the best value for their money.  I understand that they want to avoid that.

But, don't get discouraged.  Localizing Mozilla products is complex and there's much to learn if you are new.  Instead of bothering everyone with our differences, let's withdraw and agree on a plan of action, so we can move forward as an unified team.

I will be sending emails to Milos and you, so we can see where we are and how we move forward.

> Do you think it could be used in a way that could provide that translations
> flexibility that I have in mind, to be free to make our own translation, 
> without need to be the same as ff/tb?

The version control tools are just that, they are not silver bullets that magically solve all the issues.  Again, let's align our viewpoints offline and proceed once we do.

You will certainly have the freedom to roll your own translation; but I am certain that it won't be accepted by Mozilla if it is not in line with the rest of the l10n code base.

> I think that effort to include uncontrolled strings from another project to
> SeaMonkey translation, just because they ¨are there¨ will not result in rising
> quality of translation.

What you are saying here is contrary to all the human engineering experience.  I won't hammer this point in anymore.

> I am also thinking.. If Seamonkey is community product (And not Mozilla company
> product, but using only its Infrastructure)

I don't know the exact status of SeaMonkey, but for as long as Mozilla is a stakeholder, their opinion has to count.
(In reply to comment #15)
> I am also thinking.. If Seamonkey is community product (And not Mozilla company
> product, but using only its Infrastructure)
> Why it is so important and ¨must have¨ to have same strings on Mozilla-based
> applications?

As SeaMonkey project coordinator, I can tell you that there are no "Mozilla company products". ALL Mozilla projects are of the community and all of the applications (Firefox, Thunderbird, SeaMonkey Lightning/calendar) are community products, independent of any professionally organized entities ("corporations" or whatever) being involved in that community - they are parts of the community, not the other way round.
It's one single Mozilla community, not fractions for different products, and we share a quite large common codebase - which is reflected in localization as well: the platform parts (toolkit, dom, etc.) are sharing their localization for all those products.

Of course, that means we have some common threads of how things are organized, and for example means that we have one single Mercurial repository per locale (and branch, but that doesn't matter here) that contains all localizations we're using for all our products.

That also means that any localization effort only can happen in collaboration of all those people working on those projects.

In case of Serbian, https://wiki.mozilla.org/L10n:Teams:sr lists the responsibilities in that community, and Filip as the "toolkit owner" is regarded as the general leader of Serbian Mozilla localizations, so from our point of view, he's to decide how things can work inside your part of the community.
Also, I see Milos being listed there as the owner/leader for SeaMonkey-specific parts of the Serbian localization, and that usually means that Filip has decided to give him that responsibility, which for you means you need to work with Milos on it - together, not against each other. I'm sure he appreciates help, there is a good number of strings that are in the "suite" directory and therefore need some kind of SeaMonkey-specific work.

I encourage you to work together with the Firefox and Thunderbird localizers and also take their localizations for similar things into account, possibly make them the same on both sides (that can easily mean at times that you find a better localization and they adopt it as well, in others it will probably mean you adopt theirs in the end), as that eases the work and usually makes quality better for all users of all the Mozilla products in your language.
Things work that way for us in the German community and we're quite happy with it, even helping each other out where needed (e.g. when the Firefox, Thunderbird, SeaMonkey or calendar guy is busy/away, someone else can care about an important opt-in or announcement) - I very much hope such a positive collaboration can come into works in your community as well.

Appreciate common targets and try seeing the connecting strings instead of the separating walls - that's how constructing larger-than-life projects work.
Let me just add as the localization coordinator for Thunderbird and Sunbird that some of the differences exposed here in this bug seem to come from wrong assumptions that Nikola seems to be drawing regarding the codebase.

Nikola, there are two types of strings in our codebase:

- Application-specific strings:
  These are strings that are maintained independently for each application, 
  e.g. if you want to you can translate menuitems like "File" or "Bookmarks" 
  differently in Firefox and SeaMonkey.
- Application-independent strings:
  These are strings that are maintained in a central place in our codebase 
  and that each Mozilla application relies upon. These strings include stuff 
  like add-on manager or the strings on application update. It is impossible 
  to translate these strings differently for each application, because you'd 
  have to fork our codebase to be able to do that.

I think some of the differences in this bug stem from the fact that Nikola 
is saying that he wants to look at every string when doing the new SM 
localization and people like Milos are telling him, that this is not possible 
for the reasons mentioned above, but Nikola not realizing the background of 
these things. 

Hopefully this helps to clear this up.
Thank you both very much on high quality insights and help.
I will do my best to do precisely in a way you described and recommended ;)

I just had not be explained before exactly the process distinction between shared parts and steps in the process, so I thank you very much.

In meantime I had the same conclusion that shared parts in translation could be
improved and contributed to and maybe made better in the process and that
we have separate parts, product-specific to translate. 

Current problems include Milos`s refusal to contact with me on translation
and insisting on solely decisioning without explaining it and his Idea to import product-specific sections from FF to Seamonkey directly wit no overlook, 

But Filip Miletić is currently doing its best to coordinate effort and we are currently in contact in solving problems.
Only unsolved problem is that Milos is repeatingly sending me messages trying to lure me off from project.
But i think we can manage that in this stage.
Thank you again on putting thingsd on the right track :)
(In reply to comment #20)

> Only unsolved problem is that Milos is repeatingly sending me messages trying
> to lure me off from project.

I have sent you 1 pm on our forum saying that what you do is something you shouldn't, and another one few hours later saying that I have moved your very insulting post into another board on our forums and that you're officialy out of the team.

> But i think we can manage that in this stage.

No, we can't. I refuse to work again on *anything* with you or any other person that will cause troubles like this again.
@Milos: "Yes we can"
You actually removed starting translate documentation and guidance documents I was trying to provide to new members. (I did not made them)
You insulted me with several Private and now public messages trying to achieve my total subordination to you (after you already started a project) depriving me rights to discuss with others and trying to coordinate efforts in public and tried to deprive me right to put translation guidances to public for open discussion.

You insisted on solely provide all guidance, rules, control and to change rules as you deem fit without consulting anyone.

Only possible reason I see you are doing this is :
That you felt threatened, _mistakingly_ concluding that my active role is "too active" for your taste and control.

After that I made a case case publicly available and you deleted (moved) it together with deletion of translation material (proposal).
So I see now that you refusal to work with other people started because
I made your actions Publicly available.

You opted to start a team acquiring my and one more guy previous approval. 
(I had bug for it dated from 2005 onward)

After you started tracking bug, you started sending me Insulting messages and now trying to lore me from translating Seamonkey.
Your acts are not very much understandable, since I actually do not understand Why you did not explain translation problematics like those gentlemen _here_
but tried to frightened me and stalking me with private messages.

Your refusal to coordinate efforts and do everything on your own is noted and will be remembered.
Please, for all threats and insults, post an argument. You have said that I have insulted and "stalked you", so let us see...

I have not deleted your posts until you started to insult me in public, on our forums. I have deleted one post of yours by mistake, 'cause there was no way to split your post into 2 posts. Second one was deleted 'cause you posted same things you already did, and on a wrong topic. Next time you'll get a perm ban.
You are not relevant to me, anymore Milos. Any further aggressive actions you are making just further undermine you.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.