ZF-2152: YAML Translation Files

Issue Type: New Feature Created: 2007-11-05T20:07:52.000+0000 Last Updated: 2009-03-08T12:57:29.000+0000 Status: Resolved Fix version(s): Reporter: Wil Sinclair (wil) Assignee: Thomas Weidner (thomas) Tags: - Zend_Translate

Related issues: - ZF-2147

Attachments: - Yaml.php


Add support for YAML-formatted translation files


Posted by Thomas Weidner (thomas) on 2007-12-15T17:30:00.000+0000

There is a own proposal….

It is avaiable since 17.September it's under review and still not accepted. Why create a own issue for an proposal which exists longer than this issue was created ?

Posted by Wil Sinclair (wil) on 2007-12-15T20:16:32.000+0000

Hi, Thomas. It's because we're using JIRA for project management much more than we used to. If you run a query against all issues slated for 'next minor release', you'll see many with corresponding proposals. Getting the proposal approved is now one step in resolving the issue and getting the code released. JIRA has many advanced project management features with useful reports which can be easily surfaced in our wiki, so this seems to be a reasonable approach to lightweight project management. Let me know if there are any other questions I can clear up for you.

Thanks. ,Wil

Posted by Thomas Weidner (thomas) on 2007-12-16T03:38:47.000+0000

I see only one problem... I am waiting for aprovement for my proposal through the dev team since several weeks.

And issues do not need to get approved, so someone will could work on this issue as it was created by another person and integrate it (issues do not to get approved by the dev-team).

So I could come to a situation where I get the aprovement while this issue is already in work and two people are working on this. Me for the proposal and another one for this issue.

If I would not have found this by searching through recent changes I would never have known that it exists, because it is not connected to a component.

Also to mention... proposals are well thought of, and include use cases, pre-classes, API, and so on. Issues do not include this informations.

If we want to couple issues to proposals, the issues should be * connected to the proper component * attached to the committer of the proposal or the component lead or the team leader. * the related issues should also be somehow be connected to the originate proposal and not be standalone.

Just my 2 cent.

Posted by Wil Sinclair (wil) on 2007-12-16T05:51:32.000+0000

Actually, there's no problem there at all. Just assign this issue to yourself (I see you just did that), then transition it to 'in progress'. In fact, I would encourage you to break up an issue such as this that requires a proposal in to several sub-tasks, such as ZF-2117. This both registers that someone is working on it, and it allows us to use a single system for most of our workflows (in fact we could consider modeling proposal approvals in JIRA workflows in the future- maybe this is the kind of issue-proposal connection you have in mind. This will require some effort to set up- I'll take a look at it again with you after 1.5.). The only thing I ask is that you are really committed to driving this feature to release if you mark it as yours by assigning it and putting it 'in progress'. You seem pretty determined to take this one on, Thomas, so there shouldn't be any problem there. :) I'll see if we can schedule a team review for your proposal next week so we can get this show on the road. As always, thanks much for all the contributions!


Posted by Thomas Weidner (thomas) on 2007-12-16T10:50:38.000+0000

Let's say that I am a marked child... There happend several things in the past before 1.0 which broke the API, integrated problems with backwards compatibility and so on...

And I as team leader and almost only author to the I18N classes have all code and problems in mind.

What I see as must is, that all I18N classes have the same API, the same usability and if you know one you can use all others.

In the past I was a really small step away from giving all work up and let it be, because the dev-team integrated features in the past, braking existing code just 2 days before a new release. This is why I tend to make I18N my own. And I have also seen in the past that most people can only code and do not make the rest... I do not need anyone that codes and forgets about unit tests and documentation. I've made two exception... one with Zend_Timesync where Andries made 70% of the code and usecases but no docu, and another with Shreef who did only code a little bit, and I had to rewrite the complete API to fit.

But I think we should not talk about this here, because it has nothing to do with YAML translation files :-)

All things I attach to me are I18N issues... several patches from people in the past had to be rewritten before being committed. For example the date classes... this are about 4000 lines of code (2500 of api documentation) and it's pretty complex. You have to know about datemaths and Zend_Date especially before doing any changes.

When you look at fisheye you will see that I am one who commits pretty much. All my issues are closed pretty fast, when I am getting response. And all my accepted proposals are done.

Btw: Zend_TimeSync in ready since 2 weeks for core-inclusion and waits just for agreement of the dev-team to do so... or should I just integrate it ? All other proposals have not been accepted and therefor no code exists until now.

Related to proposals and issues... It's good if they are coupled because I think people are more working with jira than with the proposals page. But the proposals have one big benefit I won't miss... they are a sort of documentation and are well thought of. The issue tracker is more a sort of project management, to collect what to do, the progress and so on.

In the past weeks I saw that the unassigned issues are raising... I thought that issues have to be connected to the components lead. If there is any patch it should be attached to the issue, reviewed by him and then be committed. Are there so much components which do not belong to a lead ?

Posted by Thomas Weidner (thomas) on 2007-12-22T16:54:50.000+0000

Implementation for Zend_Translate_Adapter_Yaml.

Posted by Thomas Weidner (thomas) on 2008-02-03T08:16:25.000+0000

I erased the underlaying proposal due to the fact that it must depend on Zend_Yaml and since 10 months there is no decision or work on it.

As the already existing and working code for this adapter has not been accepted I erased also the related issue.

Posted by Wil Sinclair (wil) on 2009-01-14T14:55:26.000+0000

I'm reopening this issue to add links and come to full closure on how to proceed.

Posted by Thomas Weidner (thomas) on 2009-02-20T11:36:03.000+0000

@Wil: As you reopened this issue and nothing happend since then I would like to know how to proceed. I am not allowed to solve it due to missing Zend_Yaml but still it's attached to one of my components.

I would ask to close this issue when there is no further progress.

Posted by Thomas Weidner (thomas) on 2009-03-08T12:57:29.000+0000

Closing again as there is no progress since almost 2 months and one month after my question for clearification.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.