Language packs and translations

[eddieajau]

Need to talk to the TT's about how decoupled extensions are going to work in terms of translations.

[eddieajau]

Do we agree that it is more convenient for the user if all the translations are shipped with the package they download from the JED (or use the Store UI)?

[Hils]

Personally I would say no. If one just wanted, say, Italian only, to download another unneeded load of translations (which could be nearly 100 or more) as well doesn't make sense. As I mentioned earlier, Daniel's cTransifex gets over this problem by enabling users to connect direct to github/transifex for the latest translations as and when they want. https://compojoom.com/joomla-extensions/ctransifex-language-distribution-made-easy

(cTransifex is a Joomla component)

It also should be noted that not all extensions need translating fully. Some users might only need the front end translated whilst the backend remained in en=GB

[eddieajau]

Personally I would say no.

If that's the case, I can close this issue and marked it as "for others to solve" :)

[infograf768]

For Weblinks, that's about 15k per language (component and module)

[Bakual]

Including all languages in the extensions has two big issues:

• You need to release a new version just for updated/added languages. Especially for com_weblinks it could mean that we have several releases only for translation stuff.
• You can't fix typos in translations fast by just releasing a new language pack. It would need to wait for next release of the extension.

I currently do both in my own extension. I pull the translated languages from Transifex and include them with the package. And I use cTransifex to build the language packages and made them available with a single click in the backend of my component. However I'm considering removing all languages except en-GB. They blow up my package and only complicate the release process (and I tend to forget pulling down the translations anyway).

On the other hand, it will become tedious if you have to install and update language packs for each core extensions individually.

[eddieajau]

You need to release a new version just for updated/added languages

Yes. That's typical of almost any other "device" application I can think of.

Especially for com_weblinks it could mean that we have several releases only for translation stuff.

I don't see that as a big drama.

You can't fix typos in translations fast by just releasing a new language pack. It would need to wait for next release of the extension.

While we aren't there yet, releasing should boil down to the push of a button (aka running a few phing commands). A typo would generate a new patch. A new language file would probably trigger a new minor. Ideally we can have the system so highly automated that we could release once a day if we so choose.

And I use cTransifex to build the language packages

I think that's ok for you to decide to lock into one vendor. Should core extensions lock into just one translation vendor?

Hrm /me scratches 3-day old stubble in deep thought.

If we can make cTransifex vendor agnostic, and write plugins for different types of translation sources, would that work?

[Bakual]

I don't see that as a big drama.

Not saying it's a drama. Just not ideal. I'm going from my experience with the german language pack where we already had a few times multiple versions for a given Joomla release. Like for example 3.2.3v1 and 3.2.3v2 because they found typos or whatever after their first release of the pack. That's fine for a single pack. But you likely don't want that to happen for each extension.

that we could release once a day if we so choose.

Together with above, I'm not sure if admins will love seeing an update package for a core extension every other day. Only to fix a typo in a language file they don't even use. :smile:

I think that's ok for you to decide to lock into one vendor. Should core extensions lock into just one translation vendor?

It doesn't matter which tool you use. cTransifex generates regular packages and lists them for download. You can do that with whatever tool you like, from whatever translation source.

[dongilbert]

I've been thinking about this a while. In my sleep and in the shower even! "How can we solve this issue?" Well it just occurred to me that how @eddieajau and I and the others at the code sprint in Feb discussed things, the optimal solution for this currently is for the strings to remain in core, as much as I dislike it.

Andrew, I'm sure you remember but I'll repost it here for others, but the team decided that removing com_weblinks wouldn't be a BC issue because we are leaving it in place for existing installations, and only removing it from new installations. If we remove the strings from core, then it's a BC issue with those who have existing installations. As much as I hate to say, it's my feeling that these do need to stay in core until 4.x because of this aspect.

[brianteeman]

Good point there Don about the upgrading sites.

Thats an issue in itself that I dont see being addressed anywhere here. How do we deal with upgraded sites and make sure that they still get the updated core xtensions (perhaps another issue not this one)

[Bakual]

How do we deal with upgraded sites and make sure that they still get the updated core xtensions

That should actually be quite easy to do. On an update, we just enter the new updateserver for com_weblinks and they should see updates from there.

[eddieajau]

If we remove the strings from core, then it's a BC issue with those who have existing installations.

You wouldn't remove any Weblinks files when upgrading to 3.4+. My assumption is all the upgrade does is add the sql to register Weblinks as a standalone package. The one thing we will need to double check is if, today, you can fully uninstall Weblinks. We will need to do that before 3.4.

[infograf768]

@dongilbert has exactly stated what I was trying to convey in my first post. https://github.com/joomla-extensions/weblinks/issues/2#issuecomment-39821391

For your info, when we took off geshi from core, most TTs with existing packs kept their geshi ini files in their packs. The reason was simple: any older install would have geshi (and possibly could be in use), but no language file in case of deleting a language pack and later on reinstalling it. The difference between geshi and weblinks is that it disappeared entirely from our releases and was not a "core supported" extension, therefore would never have to be updated.

Let's go further: this does not concern only decoupled extensions, but also added "core supported" extensions (For example the GSOC ones). This without even considering a good way for ALL TTs to participate to the process easily as I explained above.

Adding all language files for an extension represents around 750k (for +-50 languages). As of today we have no way to download/install a specific extension with only specific languages. Not even taking into account the fact that a said user may need another language later on in the site building process.

Postponing such a drastic change to all our processes to a time when we can really master all aspects of them is simple realism.

[eddieajau]

Ok, so are you saying that installing a language pack designed for 3.4 into an old Joomla 3.2 site is what you are worried about?

[eddieajau]

So is this the problem: I have a Joomla 3.2 site with fr-FR. I upgrade to 3.4. I delete fr-FR (removes old weblinks language files). For some reason I install the new 3.4 fr-FR language pack.

Result: Weblinks does not translation in fr-FR because it is missing from the core language pack.

Is that it?

[infograf768]

That is one of the problems, yes. But it goes further as I explained above as it also concerns "core supported" extensions.

[eddieajau]

What is the order of precedence for loading language files? Do we look in the component folders first or last?

[eddieajau]

@infograf768 it won't be a problem as long as you have installed the language pack for the decoupled Weblinks. The same will go for any other extensions. It will be your responsibility to install the appropriate language packs for the individual extensions.

[infograf768]

Which extension language packs? How will they be proposed? How would a user know where to find it? That is not BC at all. We are losing B/C. You are refusing to understand the obvious: just leave the inis in core... and sync them with the specific weblinks repo. I leave this chat. I can't explain more.

[eddieajau]

Which extension language packs?

That's what I'm asking you to help solve. My initial reaction is we could just include all of them in the build, but you don't want to do that. So:

How will they be proposed?

That's another good question. What do you suggest?

How would a user know where to find it?

And another good question. If they aren't included in the build, how are we going to help the user find them? Can the JED help? Do we need to work on some new functionality in the CMS itself to be able to do this?

That is not BC at all. We are losing B/C.

I think that's a rather extreme point of view.

You are refusing to understand the obvious: just leave the inis in core... and sync them with the specific weblinks repo.

You need to take that up with the PLT. If that's the case, there is no point whatsoever in decoupling at all.

[nicksavov]

Andrew, in short, he's suggesting keeping things exactly the same as they are for TT teams today. This is the simplest solution, works well, and preserves backward compatibility.

If PLT is OK with it, I can post the Language Keys section of the new development strategy in here, which should help with this discussion. I'll double check.

[eddieajau]

@nicksavov I've posted some questions for the PLT on the mailing list. There is no point in doing any more work on this until those questions are answered. If the language strings need to be kept in the core repo, there is no point in continuing with this project (no point in decoupling it to 80%).

[nicksavov]

Good idea

[stellainformatica]

I agree with JM, the best solutions for TTs is to always include the extensions language strings in the full CMS. It is the simplest way for our TTs, they already have to manage 3 language packages and will become 4 when 3.4 will be released in July, so please don't complicate the things and leave that few language files in the core, I don't think this will be a issue.

About Transifex, I don't think it's a good way to manage the language packs, I had a bad experience with it when I had to correct and add some italian language strings for Tinymce, and finally I decided to modify manually the language file of Tinymce for Joomla.

The best solution would be to create a special tool for joomla, a unique tool to give to translators, which overcomes all the problems that give the other instruments known. I mean to create it from scratch, as for the new jed that has been commissioned to an outside firm, or as the new tracker that has been made ​​by the team.

Stefania Italian TT Coodinator and TT Coordination

[Hils]

Stefania

A translation tool for Joomla will take years to develop to the standard of Transifex. Transifex has now five years experience and has changed dramatically since you looked at it eight months ago. If it is relevant to this discussion, the old ideas about Transifex should really be rethought and properly evaluated.

[daviddeutsch]

Having spent the last year thinking about packaging and breaking up software, this thread is a serious head-scratcher for me.

First off: It's OK if things have a different structures for different steps of the process! A repository does not necessarily need to be in the same structure as the installation of the code later on. Similarly, a package does not need to be the same.

Second, I think a lot of the thought processes in this thread are tangled up in a similar way and I'm surprised that very few people understand it as what it is: a simple interface problem. Of course there is no silver bullet solution, which makes it easy for some here to argue that the easiest and cleanest way would be to simply keep doing it the same way it used to be done.

Because making Joomla more flexible and modular is a issue close to my heart, I urge you to be a little more imaginative.

What all this comes down to is a question of: How will this get packaged? In Joomla, we have separate packages for components and for languages. The disconnect comes into play because we also have packages that can have components AND languages. I suppose most people here care about having one canonical component install package that also serves en-GB with it.

Why not do all of those things?

I suggest we need one bare component package without any language files, separate packages for the languages and a kind of bootstrap package that installs the component and the en-GB translation.

Now, for the concrete structure, we can have one /language directory for each of the directories that will end up being a package. That way, you have an atomic structure and your translations are contained with the code they are related to.

/com_weblinks
/com_weblinks/language
/com_weblinks/language/en-GB
/mod_weblinks
/mod_weblinks/language
/mod_weblinks/language/en-GB

Then, when the repository is packaged, add a step that extracts the individual language directories so that you get the packages:

/com_weblinks/language/en-GB -> com_weblinks-language-en-GB.zip
/mod_weblinks/language/en-GB -> mod_weblinks-language-en-GB.zip

Remove the /language directories and zip up the functional bits:

/com_weblinks -> com_weblinks.zip
/mod_weblinks -> mod_weblinks.zip

And, if you want to, make another set of zip files like:

com_weblinks-language-en-GB.zip + com_weblinks.zip -> com_weblinks-en-GB.zip
mod_weblinks-language-en-GB.zip + mod_weblinks.zip -> mod_weblinks-en-GB.zip

Which would simply have both the component (or module) and the translation as individual installables.

The only thing left to do, then, is to link these language files in the repository to a service like Transifex, which provides a client to pipe through .ini files to their way of doing things.

As a final note: All of the problems that are being talked about here are well known and well solved in FOSS development. Please let us not pretend like we're the only ones having them and let's especially not pretend that there aren't proven and well working solutions that we can use (if with a little bit of creativity) for our particular situation. The thought process can not be: Oh this one way of doing it that I've seen is incompatible with how we do it, so of course we need to roll a solution that is 100% our own.

That's how wheels get reinvented and how good minds are wasted solving solved problems.

[mbabker]

Realize that this is "the great experiment". We don't have a precedent for removing a component (and its supporting extensions) from the core distribution and supporting it separately. For years, we have focused solely on the monolithic package we distribute today. There's nothing wrong with that; the maintenance is overall simpler (everything in a centralized location), our workflows have been established for years with the current setup, and as some people have been undoubtedly thinking since the announcement of this goal, "if it ain't broke, why fix it?".

This is new territory. It's going to take time to establish something that works for all of us and trying to rush to a decision isn't going to help anyone. At the same time, being unwilling to explore change and new possibilities is going to inhibit us from one day reaching a goal of a slimmer core distribution and being able to dump the excess fluff. I look at the unused components on my sites the same way I do software on my personal systems; if I'm not using it I want it gone. I doubt everyone uses com_weblinks on every site they build, how many people want to update the full CMS package just because a security issue is discovered in that code (not implying there are any, please don't misconstrue that!)?

Regarding the language stuff, personally I think we set a bad precedent in allowing the Install from Web plugin's language file to be shipped with core even though the actual plugin is an optional install. That fact alone can be used to strengthen the argument to retain all core supported language files in the primary language (en-GB) in the main distribution. It isn't architecturally right. I'm pretty sure it's a JED rule that there should be no trace of an extension if it isn't installed on a site, why should core extensions be treated differently?

I think many of us watching this thread or offering opinions have a legitimate interest in seeing the CMS move forward and achieving the goals that we all have for it, but also recognize there are issues with the current workflow which are 100% unrelated to the software. Some issues are going to need to be addressed in working towards this particular goal, but we should do so with an open mind instead of "status quo wins unless you have a working solution already". Don't be afraid to experiment a little.

[Bakual]

What is the order of precedence for loading language files? Do we look in the component folders first or last?

Joomla first looks in /language and if the file isn't there, it looks in the component folder. Making an example with german:

1. /language/de-DE/com_weblinks.ini
2. /components/com_weblinks/language/de-DE/com_weblinks.ini

That means you can for example override a language file by placing a copy into the global language folder.

Best practice is that language packs go into the global language folder while languages bundled with a component reside in the component folder.

It's also to note that language files in the global folder are deleted if the main language pack of that language is uninstalled, while those files in the component folder will stay there.

[daviddeutsch]

@mbabker

This is new territory.

It is and then again it isn't. Keep in mind that a sizeable portion of the joomla community has been working in precisely that way for almost a decade now. So the precedent we should be looking for is all around and the solutions that have emerged in the 3PD community have been the result of exactly the kind of search that others in this thread propose still needs to happen. For instance - there are reasons why hardly any developer these days has her code on joomlaforge and there are reasons why so many developers use the services of Open Translators. A lot of feet have already cast a lot of votes.

I am getting a sense that there is some resistance to changes like the ones proposed here because it does blur the boundaries of what is the joomla project and what is development around the joomla project. But I think that's a very good thing.

One of the strongest points of joomla has always been the community of developers around it but unfortunately, there has been a certain antagonism in the dynamic between project and the developer community. There is no need to rehash those arguments, of course, but I would say that projects like this small one here will do wonders for calming the tides.

A monolithic package and a rather centralized project, as you've put it, may indeed be easier to manage, but it also creates an us-and-them and (still treading carefully around some open wounds) it has created a number of self-serving cycles that do little but use up peoples time and energy in maintaining the status quo.

"if it ain't broke, why fix it?"

Indeed some people think that, which is unfortunate, because most of the people I talk to say the exact opposite. My guess is that very few people actually believe it, let alone that they would be hard pressed to actually support their argument with facts. Centralization works until a certain degree and then the cost outweigh the benefits and it is my impression that joomla, unfortunately, is way past that mark. But that is the computation we should make: Do the benefits of the new way eventually outweigh the cost of change. In my opinion: A resounding "absolutely yes".

Splitting up the codebase into more managable parts that can be serviced by smaller teams that are more open to influence from the community - simply because the barrier of entry is no longer "this must be fit for the one big package" - will do absolute wonders for collaboration and bringing new people to the table.

Realize that this is "the great experiment".

On the one hand I agree with you - Whether or not joomla is able to decentralize and let go of control will determine its relevance in the market place in the future.

On the other hand: What's with the pathos? In my view, joomla needs to finally come to terms with the facts and make some obvious, even self-evident decisions that have been long overdue. Pitching it up as a gloom and doom event (you only hint at it, others go the whole nine yards) does not help. Let's focus on making new, wonderful things happen even if that means cutting ties with some old and comfortable, yet outdated and ultimately wasteful ways.

[eddieajau]

So I'm looking at the big picture here that the Core Joomla is going to get lighter and lighter and we are going to have more and more of these Extra extension packages. Let's even imagine that a project like Kunena says, stuff it, we want to be an officially community support forum solution for the project (I'm not suggesting they should, but just imagine we have all kinds of Extras, maybe even commerce solutions or CRM's).

On that basis, this problem is not going to go away and just stuffing more and more language files in Core Joomla is not going to work. Eventually the amount of ini files will exceed the PHP (well, maybe not but you hopefully get my point). So I encourage everyone to lay down their preconceived ideas and think outside of the current processes. We are going to need a different solution in the future. We need to start thinking about this now.

To that end my current thoughts are:

1. We can store all language files for all translations in this repository. I doesn't matter how they are created, but in order to make builds, we need them located in a single place.
2. It's not practical to ship all available language files in one build. We will need to think of ways of building the individual language packages for each translation. But this is new so we need to work out how people can install the language packs they need.

Brainstorming time. Thoughts?

[eddieajau]

Ok, looks like this is a dead end. If the language files remain in the CMS repository doesn't that mean Weblinks is going to have to wait for the CMS to release to make even the smallest change to the language files? That's going to be as frustrating as hell to deal with.

[infograf768]

One possible solution (at this stage) could be that weblinks ships and contains only the en-GB inis. When a change is made, it would have to be synced into the CMS whatever the change. Information would be transmitted to the TTs (via the TT Coordination which would provide a lang .diff). We would make sure all TTs are informed, and they would be able to release an updated pack for the latest official version of Joomla. (As you know we now can do that easily as we now use a 4 digits version of the pkg and a cron between our specific repository and update.joomla.org).

Let's say you are ready to propose an updated weblinks package and decide of a language freeze, we would need around a week to get as many CMS lang packs updated as possible. If a pack is not updated in time, the English values would at least display (instead of the constants, recent improvement in the 3.x and 2.5 series), and end-users would be able to create overrides in the meanwhile.

Obviously, getting the TTs in the process would only be necessary if new strings, not for English spelling mistakes.

[eddieajau]

One possible solution (at this stage) could be that weblinks ships and contains only the en-GB inis.

Ok - if the en-GB files ship with Weblinks that means they are the "master" copies, right? So translators would have to work off them. The language files in the CMS would be out of date, so is there any point in keeping them there?

[infograf768]

Again, asking Translators to look all over the place for possible updates is not feasible at that time. We would furnish the .diff, but some tools work FROM the files in the CMS and we also maintains the install.xml(s) there. Therefore they have to also be in the CMS. As I suggested, just sync them...

[eddieajau]

As I suggested, just sync them...

The current workflow is you have to prepare a pull request and then get two testers. That can take anywhere from days to weeks to have that processed. That's not practical.

[daviddeutsch]

@infograf768 With the right tools, translators would not have to look for updates at all, that's the point. Also: "just sync them"? Tackling reliable sync can be one of the hardest tasks I can imagine and if it can be avoided, it should be. If you're worried about translators being confused keeping track of a handful of repositories (which I don't agree with, but the point is moot anyhow), just add Tags and Branches into the mix and a tough situation (that we can resolve entirely with the right tools) becomes an impossible one. Data and Code should be where they belong and pulled only to where they are needed.

@eddieajau I don't see many people left in this thread arguing to keep languages belonging to an extension repository in the main repository, so I think we agree that at the very least en-GB should be in /weblinks as the master reference. The only reason against having language files in that repository, so far, have been that it might be more in line with how translation work has been done previously, but in my opinion, it should be obvious that the cost outweigh the benefits. Whether or not the other translations are also added into the extension repo depends more on what would best suit the translators

The only thing that is left to discuss is: How would this be packaged if the files are indeed separate? I have made a number of suggestions, but would be curious to hear what ideas others have on that matter.

[eddieajau]

How would this be packaged if the files are indeed separate? I have made a number of suggestions, but would be curious to hear what ideas others have on that matter.

If you think it's worth battling on, go for it.

[infograf768]

@eddieajau Such changes for a core supported extension language files are taken care of in a day max. I would personally take care of it.

@daviddeutsch

With the right tools...

...You want to change the present working system. I have nothing against "progress". As of now, we do NOT have a new system and keeping posting that Data and Code should be where they belong does not help to solve the present situation. It looks like you think like a developer, not a translator. It seems you are unaware of all what we have to do to get some languages for core. And I repeat: NO, the majority of TTs do NOT keep track of any repository, not even the CMS one.

The only thing that is left to discuss is:

The only thing? Where would the TT files be? How would that be organised? Do we want to pursue the necessity for any "core supported" extension to also have all language files corresponding to the Core lang packs and overlooked by TTs? Or just decide that TTs do not have to support them at all and it will from now on be a totally different game?

I don't see many people left in this thread arguing to keep languages belonging to an extension repository in the main repository

If by "main repository", you mean the CMS, I suggest you read better above.

In any case, research/experiments on new tools/processes are great, but please, do not confuse translators with coders and do not try to force a coder's solution in such a short term. These matters are not framework type.

[daviddeutsch]

@infograf768 I have added plenty of suggestions on how to organize it and further suggested what kind of people we should ask for additional insight to balance or amend my viewpoint. Also: I may not be a translator, but a lot of translators and people who mainly work with translators have weighed in here and I have discussed this with a number of folks in private. I do not confuse translators with coders - the kind of interfaces that I and others have suggested here are precisely for bridging that gap.

It seems you are unaware of all what we have to do to get some languages for core.

Perhaps I could encourage you to entertain the possibililty that I spend a rather excessive amount of time considering the exact amount of effort that is going into maintaining the status quo.

[eddieajau]

Such changes for a core supported extension language files are taken care of in a day max. I would personally take care of it.

I don't think that's good enough. The system breaks if you aren't there and that means the system is brittle. I don't want to see contributors having to go to 20 different places just because 19 of those people don't want to work towards a common solution that helps everyone.

Perhaps I could encourage you to entertain the possibililty that I consider the exact amount that is going into maintaining the status quo with rather excessive depth.

That's an understatement!

[daviddeutsch]

Perhaps...

I quite like how it's now my original wording (in your comment) and my "attempt to make more sense" rewording out on display :smile:

[Hils]

There has been a lot of talk about 'official translation teams' which is good. Perhaps it is now time to open up the official process and workgroup generally as most of their discussion is done in private: http://forum.joomla.org/memberlist.php?mode=group&g=47&sid=f2850518a55c9cd38858a95df5bb6d48 . Then everyone could have an informed discussion.

[eddieajau]

Hils, I think that's important, because I think this type of structure is the way forward for Joomla. That is, Core Joomla is very light and features are extensions. There are at least 4 extensions to follow in 3.5 and hopefully more to be added to the offering. Saying "let's just chuck the language files in the core" is not going to work, so we might as well start solving that problem now. Apart from that, I think the project does a good job at looking after itself but not the 3PD community, and this is something I'd like to solve as we look at Weblinks.

[Bakual]

The current workflow is you have to prepare a pull request and then get two testers. That can take anywhere from days to weeks to have that processed. That's not practical.

The system breaks if you aren't there and that means the system is brittle.

Just a few comments. You are of course correct that this is not practical. But as JM said, it's not how changes in language files are handled. They are not required to have two testers (it's one of the exceptions to the rule, typos and codestyles being others) and can be merged fast. JM is also not the only one who can merge PRs. So I don't think that will really be an issue. It's of course not perfect, I think all agree. But it would work.

[infograf768]

First, the term "Official Translation Teams" does not exist, but only "Registered Translation Teams". Second , all TTs do not form a Working Group. Only the Coordination is one. We do have indeed a Private Forum for TTs where we post informations, share issues, and prepare new releases.

When a specific concrete proposal will be made here, we shall inform them and discuss. For now, we concentrate of 3.3.0 new lang packs.

[FYI, a member of OT (also TT) tried to force all TTs to get into a "kind of OT" project on Transifex by transferring there their packs "without their approval". It was strongly opposed as, among other issues at this time, the system on Transifex did not keep their copyright in the ini files. That TT by the way has not released his core pack for a while and did not even update the installation lang file. Therefore, as his first pack was very obsolete (3.0.2v2), we had to take it off from the common repository]

The Coordination is aware of this discussion, as posted above by Stella. For Marijke, she has explained at length for a long time now why we did not support the OT system in Transifex, as not good enough for Core languages. See also above some technical concerns we all have.

Therefore, no use to send all the OT lobby here. It may work for few strings for 3pd extensions but not for core for all the reasons we have explained multiple times. (It does not mean that some TTs should not use Transifex as an independant project and then correct the results to make their packs: it is their choice.)

Last, we have started a new project to correct and improve com_localise. See https://github.com/joomla-projects/com_localise

Once this component has been completed to fulfill its original roadmap, my hope is that we can make it interact with Github/any_web_app, in order to fetch/push to any place appropriate the files (inis, .js, .css, zip and xmls) or packs.

Volunteers welcome. That is a concrete joomla project...

[daviddeutsch]

It may work for few strings for 3pd extensions but not for core...

Having individual components treated more like a 3PD project is precisely what this should lead to. It's a good development and an overdue one.

...for all the reasons we have explained multiple times.

The only reasons I have seen so far are excuses that it would be hard to change a running system or that with this or that particular bridge, it might not be simple. Doesn't mean it's not possible. And: that still says nothing about the cost-benefit analysis.

Once this component has been completed to fulfill its original roadmap

So what? There are tools working now, being used for what we're discussing here now. To restate my earlier point: You're asking to waste minds on solving solved problems. Why? Qui bono?

Volunteers welcome. That is a concrete joomla project...

The argument is being made that the project should be less centralized and more embracing of appreciating and coordinating outside efforts instead of reinventing the wheel trying to do everything as "a concrete joomla project".

To be brutally frank: I think joomla has lost it's bargaining position to ask in that manner. People are not coming to the table. That's the problem. Maintaining the status quo is not how you fix that.

Finally: The FYI anectode you mention is simply the kind of coordination fallout that can happen when things are decentralized. Nobody is seriously hurt because some parts of a community try something different for a while and fail. It's a price you pay, you just deal with it and move on.

[Bakual]

The argument is being made that the project should be less centralized and more embracing of appreciating and coordinating outside efforts instead of reinventing the wheel trying to do everything as "a concrete joomla project".

Just for information what com_localise is, since I didn't know it myself before this discussion started. It's an existing component translators can use to translate any Joomla language strings locally in their installation. You can select the source language you want from any of the installed languages and can translate to any other language or even simply create a new language pack. It creates the needed XML files from information filled out in an edit form. You can translate the strings using an interface similar to Transifex or you can edit the files directly using an inbuilt editor. It takes care of double quotes (" are converted to QQ) and shows you syntax errors. Imho, it goes quite beyond what regular translation tools do and is quite nice already. However it has some nasty bugs and needs some love desperately.

So please don't shoot it down as "reinvent the wheel". It's not. It's also not a new tool.

[wilsonge]

It is a new tool because a large amount of it doesn't work in the desired way. That's why we've forked it from it origins put it on github and are working on it.

On 14 April 2014 14:08, Thomas Hunziker notifications@github.com wrote:

The argument is being made that the project should be less centralized and more embracing of appreciating and coordinating outside efforts instead of reinventing the wheel trying to do everything as "a concrete joomla project".

Just for information what com_localise is, since I didn't know it myself before this discussion started. It's an existing component translators can use to translate any Joomla language strings locally in their installation. You can select the source language you want from any of the installed languages and can translate to any other language or even simply create a new language pack. It creates the needed XML files from information filled out in an edit form. You can translate the strings using an interface similar to Transifex or you can edit the files directly using an inbuilt editor. It takes care of double quotes (" are converted to QQ) and shows you syntax errors. Imho, it goes quite beyond what regular translation tools do and is quite nice already. However it has some nasty bugs and needs some love desperately.

So please don't shoot it down as "reinvent the wheel". It's not. It's also not a new tool.

— Reply to this email directly or view it on GitHubhttps://github.com/joomla-extensions/weblinks/issues/2#issuecomment-40363181 .

[daviddeutsch]

So please don't shoot it down as "reinvent the wheel". It's not. It's also not a new tool.

I do understand what the tool does (or is supposed to do), but @infograf768 argued that it needs to be finished and extended to provide the functionality that is required for what is discussed in this thread. Since it would be possible to solve the problem with other, existing tools (and 3PDs already do that), I don't think it's unfair to say it would be reinventing the wheel.

[Hils]

No-one should be here to shoot ANYTHING down, ever. All I, personally, nothing to do with OT, wish is that the project could move on and consider embracing crowdsourcing translations, obviously with translation reviews (checks & balances), as a viable way forward. Translation Memory is invaluable for example.

Are we uninventing the wheel perhaps?

[horus68]

@infograf768 related to statements on your reply https://github.com/joomla-extensions/weblinks/issues/2#issuecomment-40360647 that involves me directly I have to make some corrections. I don't want to get along in further conversations as this is not the issue here!

That TT by the way has not released his core pack for a while and did not even update the installation lang file. Therefore, as his first pack was very obsolete (3.0.2v2), we had to take it off from the common repository]»

infograf768 is talking about me, horus_68 the Portuguese (Portugal) language coordinator. Portuguese Joomla Community only supports the latest LTS versions, so no 1.5 and no 3.x (we do have a finished translation for J3.x available to all users, only not packed. So any early adopter for 3.x that "can work without support" can also create their packs. But when we create packs for our language we have other issues to consider as it will say to all governement portuguese sites: its time to use J3! That's our option and you should respect it... or ask us why! Also note, that after the recent Joomla release cycle changes, we will release a language for Joomla 3.4 and drop Joomla 2.5 support. Note that we are translating Joomla core (site and administration) since Joomla 1.0 (using then a special distribution pack because there was no translation files for administrator).

tried to force all TTs to get into a "kind of OT" project on Transifex by transferring there their packs "without their approval".»

False: This is not a kind of OT: this is a single project to translate Joomla. As for many other extensions. I set things up for my language and open it for all others. On transifex a project can have as many languages he creates teams to! It was a very detailed and documented move, each language team translation coordinators was informed on private translator forum and skype chat and invited into it. This would give any project on transifex also a translation memory form core files. Several declined to use transifex and the language was removed from the project to translate so no double packs. So some uses it and others don't use-it! No big deal!

Note: some asked to be removed because they already used other tools, others because already had their own project on transifex and other because you simple ask them not to or/and created panic on stolen files!!) BTW: you are free to publish files from Joomla, keeping the copyrights. So...?

It was strongly opposed as, among other issues at this time, the system on Transifex did not keep their copyright in the ini files.

Not true. The system keeps the english copyright as its supposed to do. The copyright on any language files are already considered on XML files as you told me before. You also know that the copyrights from joomla core installation ini files was also removed on the same ground! Maybe Joomla should have a field for copyrights on language files, but this is not the case.