Apr. 10th, 2009
Translation strings for email messages
Apr. 10th, 2009 03:08 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Quick note based on something that I've just seen.
When you're updating translation strings, remember that not all of them will be shown on the website itself. There are a lot of strings that are used for various emails that we're sending out for one reason or another. Before you add any HTML to a string (eg <strong> or <em> tags) try to make sure that you are editing something that's ending up on the web.
When you're updating translation strings, remember that not all of them will be shown on the website itself. There are a lot of strings that are used for various emails that we're sending out for one reason or another. Before you add any HTML to a string (eg <strong> or <em> tags) try to make sure that you are editing something that's ending up on the web.
Bringing in more people
Apr. 10th, 2009 06:42 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
This entry isn't really going to be saying anything concrete. It's mainly just me putting some of my thoughts onto pixels. I'd very much appreciate any thoughts that any of you have on this, though.
At various points, from when I first took over the documentation project to this morning, I've had various people expressing an interest at getting involved with FAQs/copy/proof-reading/whatever and I've had to turn them down, for one reason or another. It breaks my heart a little bit every time I've had to do that, because I really firmly believe that everyone has something useful to offer and everyone should be able to concentrate.
The problem, for now, is that expediency is trumping pretty much all other concerns. We have a bunch of things that we need to get written by Open Beta, and getting them written is my priority. Paradoxically, asking more people to contribute at this point would be counter-productive to this goal. Time spent training people up to write in our style and to use our tools would take away from the time we have to actually write things.
In choosing my teams, one thing I was looking out for was people who I thought would be able to get writing with minimal training: people who were self0sufficient in learning new skills, for instance, or people whose natural writing styles mostly closed matched the Dreamwidth style.
Fortunately, writing documentation is a lot like writing a book. It's impossible to ever finish. There'll always be some wording that could be made clearer, some feature that isn't documented properly, or some new way of presenting things. No matter how good our documentation is, we'll always be able to make it better.
As we move on after the Open Beta launch, I want to try to bring as many people as possible into the process. The development team are doing a wonderful job of getting new people involved and training them up (
dw_dev_training for instance) and I want to use what they're doing as a model for what we can do over here.
One of the problems will be that we don't have the same tools as the devs do. We don't have any nice mechanism for people to submit patches to update site copy or FAQs. We have just two options: either we can say "hey, I think that this should say this instead" or we can put it actually live on the site. This is less than ideal.
In the long-term, we're going to be scrapping the existing FAQ system and translation system and replacing them with new, better systems of our own devising. One thing that I'm keen on working into the new system from the start is some decent form of version control. I want for us to be able to make changes and have them sitting in the back-end where we can look at them, and then to be able to put them onto the live site when we're happy with them.
For now though, that isn't an option, so we'll have to figure out some other way of doing things. One possibility is to let everyone who's interest make suggestions for additions and improvements, but instead of just saying "yes" or "no" for us to then work with you to let you know why we think it's a good or a bad idea, how you can improve your suggestion, and so on. That way, hopefully, we'd be able to have people improve, and eventually reach the point where they'd be the ones who are giving the advice and making the actual changes on site.
I'm not really sure what the best way to try to organise this will be, nor even if it's going to be a good idea to have any sort of formal organisation at all. I just know that the general idea of bringing more people into the fold is one I'm committed to.
So what do you think? If you're currently on the team, how would you feel about helping to train up new people? If you aren't currently on the team, what would be most useful to you and make you want to get involved?
At various points, from when I first took over the documentation project to this morning, I've had various people expressing an interest at getting involved with FAQs/copy/proof-reading/whatever and I've had to turn them down, for one reason or another. It breaks my heart a little bit every time I've had to do that, because I really firmly believe that everyone has something useful to offer and everyone should be able to concentrate.
The problem, for now, is that expediency is trumping pretty much all other concerns. We have a bunch of things that we need to get written by Open Beta, and getting them written is my priority. Paradoxically, asking more people to contribute at this point would be counter-productive to this goal. Time spent training people up to write in our style and to use our tools would take away from the time we have to actually write things.
In choosing my teams, one thing I was looking out for was people who I thought would be able to get writing with minimal training: people who were self0sufficient in learning new skills, for instance, or people whose natural writing styles mostly closed matched the Dreamwidth style.
Fortunately, writing documentation is a lot like writing a book. It's impossible to ever finish. There'll always be some wording that could be made clearer, some feature that isn't documented properly, or some new way of presenting things. No matter how good our documentation is, we'll always be able to make it better.
As we move on after the Open Beta launch, I want to try to bring as many people as possible into the process. The development team are doing a wonderful job of getting new people involved and training them up (
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
One of the problems will be that we don't have the same tools as the devs do. We don't have any nice mechanism for people to submit patches to update site copy or FAQs. We have just two options: either we can say "hey, I think that this should say this instead" or we can put it actually live on the site. This is less than ideal.
In the long-term, we're going to be scrapping the existing FAQ system and translation system and replacing them with new, better systems of our own devising. One thing that I'm keen on working into the new system from the start is some decent form of version control. I want for us to be able to make changes and have them sitting in the back-end where we can look at them, and then to be able to put them onto the live site when we're happy with them.
For now though, that isn't an option, so we'll have to figure out some other way of doing things. One possibility is to let everyone who's interest make suggestions for additions and improvements, but instead of just saying "yes" or "no" for us to then work with you to let you know why we think it's a good or a bad idea, how you can improve your suggestion, and so on. That way, hopefully, we'd be able to have people improve, and eventually reach the point where they'd be the ones who are giving the advice and making the actual changes on site.
I'm not really sure what the best way to try to organise this will be, nor even if it's going to be a good idea to have any sort of formal organisation at all. I just know that the general idea of bringing more people into the fold is one I'm committed to.
So what do you think? If you're currently on the team, how would you feel about helping to train up new people? If you aren't currently on the team, what would be most useful to you and make you want to get involved?