Drupal.org provides an amazingly flexible issue queue and is the backbone of most community activity around code, community, policies, drupal.org itself and so on. Each issue has a priority value which can be one of Critical, Major, Normal and Minor. Even more interesting is the tagging system we use with some commonly used tags like 'beta blocker' or 'beta target' or 'revisit before release' which add extra priority on top of the single value field. The drupal.org issues however don't lend themselves to supporting working on your priorities. Here are some options and tools I used so far that help solve this issue.
We learned how configuration translation works on the conceptual level and through the Drupal 8 built-in user interfaces in the previous article of the series. In this article, we'll cover how can developers integrate with configuration translation.
Explaining the structure of configuration
We used your main site configuration file as an example in the previous article. Let's review that again (system.site.yml):
There are clearly some translatable elements here. Which ones? Well, at least the site name and slogan would be. How would Drupal know though? There is nothing in this file to tell Drupal about that. There is also no code in handling this configuration that needs to deal with that. We wanted to introduce language support in the most transparent way. Instead Drupal supports a static description format to describe the structure of configuration, that we call configuration schema.
After a long 8 months break in the article series, we are back to talk about configuration translation basics. Why the long break? Well, both the configuration and content system was in heavy development with changes and I did not want to get you content that would be quickly outdated. Hopefully now it is safer to talk about what is going to end up in Drupal 8 for these systems. If not, well, then I’m sorry. We’ll cover configuration first because that is more baked.
The Drupal 8 configuration system is a boon for language
As I wrote in the previous article in the series, configuration is now encompassing lots of settings that were variables or used custom settings storage in Drupal 7. The biggest value for non-English and multilingual sites in Drupal 8 of the configuration changes is that now a common system is used to manage your site name, email text settings through to views, field settings, entity form displays, etc. We can introduce language and translation support in a way that modules will need to plan with. It is not just an optional contributed add-on but a core feature.
Drupal is right in the middle of web technology, an ideal integrator of all kinds of things. Just like PHP itself it may be clunky here and there but it is a very efficient tool to build great experiences. And even if you are a great JS developer or a pro PHP person, maybe you have mad debugging skills, you always have something to learn. Now there are great books, sometimes even better videos, but nothing beats hands-on learning. When you get together with other people working on the same thing you learn so much about how they work and even if you gain no new knowledge about programming per say, you learn new tricks and ways to achieve things:
Two days working with the Drupal Community in #DrupalDevDays help you to learn more than one week working alone at home :)
Finally, by helping to improve the tools you use, you gain much better knowledge about them. Close to the start of my web involvement I worked a lot on translating the PHP documentation to Hungarian and I got into Drupal fixing core issues for translations. By becoming one of the thousands building the system you use you also gain more credibility when you are looking for help in your weak areas as well:
But not everyone can do this right? You need to be a professional programmer and pay expensive fees to get into events? Wrong! So wrong! There are always sprints around the globe and more and more local Drupal events are announced every day. Starting out with a simple issue on a one day sprint is a great start. Drupal can always be improved in all kinds of ways whether that is accessibility testing, documentation, perfecting button colors and radiuses or finding and documenting bugs. All of those are great contributions.
Drupal Dev Days sprint photo by Amazee Labs
The best places to immerse yourself in contribution are multi-day sprints though. If you have any opportunity to go to those, I would definitely suggest you join one. Why? It takes a fair bit of time to get set up, understand the issue, start providing a solution and even though at the end of the one day sprint, you will promise to get back to it a week later from home, it is almost certainly not going to happen. There is nothing wrong with you, you just have other priorities when you get out of sprint-mode. So for ideal involvement pick a multi-day sprint. It is not only that you have more time to work on things, you can get to know the people better as well on the social events. Some conferences, especially DrupalCons include extended sprints before/after the event. If you just go to the main conference days, you have much less chance to interact with people who shape the future of Drupal, while at the extended sprints, you can get involved and work with them real time. How is that for growing your potential?
Here are some examples of events with multi-day sprints where my friends from the multilingual initiative will be sprinting, feel free to add more in the comments:
DrupalCamp Spain in Valencia is coming up in a little over a week on May 16-18th. All three days have sprinting opportunities and some of the leaders from multilingual, frontend and migrations will be there!
The organizer team is still energized after our experience putting together Drupal Dev Days Europe 2014 in Szeged, Hungary between 24 and 30 March.
Several people asked about details and we wanted to document the event for future event organizers to share what worked best for us. We prepared a report for you so if you experienced Drupal Dev Days Szeged, you can look behind the curtain a bit, or if you heard about it, you can see what we did to pull off an event like this. If you were not there and did not hear about it, we included several feedback references as well to give you an idea.
Do you want to see tweets and articles like those about your event? Read the report for our tips!
We definitely did not do everything right but we hope we can help people learn from the things we did right.