Roll Call


Feature creep or not: localized log messages

Stephen: One of the assumptions has been that we want log messages in multiple languages. This was discussed at the face-to-face in August, but Likun brought up a point about fatal messages. The users of those messages do not really have to know what the message means - it is only useful for support.

Stephen: Do we actually want locale-specific messages in BIND 10? If not, then we can put the messages in the code. If we do, then we have to put the messages in one place.

Jinmei: I don't understand the concept of local something.

Stephen: Language-specific. Log messages in different languages. So if you're running the server in Germany all the messages in the log come up in German.

Jelte: If we do have localized log messages with errors, then at least we need some common token in the message itself so support could look it up.

Stephen: That's right. I did put some suggestions as to how that would look on the wiki. But before we implement the logging we need to ask if we want this. Is this a requirement of the name server?

Jeremy: I don't think it's a requirement.

Jinmei: I don't think it's a requirement either. But at the same time I also see it as a very nice feature for various operators. So depending on the trade-off between the costs and benefits we might want to give it. Also if we have the infrastructure to support that we can use the community-wide approach where we ask for translation to the external developers and users, which would also be nice in itself. I think it is a good idea, and don't fully understand the trade-off between cost and benefit.

Stephen: I suppose the trade-off is really for the programmers in that you would have to get used to the discipline of putting your message in a file, and then using a token in the code.

Shane: I thought with something like gettext() you put both a token and a default message in the function call.

[ license discussion ]

Likun: If we want to localize the log messages, do we plan on localizing the config file? Also some command?

Likun: Some other developer may be able to write some tool to do some status works on the log message, like how many query the server got in an hour, how many answered. If we localize log message this might be more difficult.

Michal: Well we want tokens that don't change in the log message. So you would not look for the explaining text. Regarding translated config file, I think that people would kill us for that. You can't have a localized config file for someone else! I hate Microsoft for localizing functions in Excel, because you don't have IF() in the Czech version you have a localized version that has an accent in it, so nobody can even display it somewhere else in the world.

Jelte: Yeah localized commands are a very bad.

Shane: Jerry Scharf's document suggested that commands should not be translated, help text should. Things like command responses or log messages could be either way...

Michal: Showing both the translated and the original is too long?

Likun: Maybe we can gather opinion from the user?

Larissa: We did not ask any questions about localization in the survey, but it should be asked. We asked if people are willing to engage in follow-on conversations. I'll see if anybody has other feedback.

Jelte: It depends on who you are asking in those surveys. If you are asking people at NANOG they couldn't care less...

Larissa: That's why I would ask a subset. But what I would love to ask the team is if you have more things you want to know tell me.

Jelte: I have a hobby project where I have localization. It is always a problem because you have to wait for your translators if you change one thing.

Stephen: If we do something like this.... if we use gettext(), then once you've specified a message that's it, full-stop. You can't change it because it would break translations. The system I propose would be to use an ID. Old messages would be translated, new messages would appear in English form.

Jelte: I suggest runtime binding. Lets first decide whether we're going to do this or not.

Jeremy: Is this something we can put off until later?

Stephen: Yeah but what are you going to log? We might as well be putting in logging in the proper format because otherwise we'll have to go through and change the logging messages later. So do you issue a logging call with an identifier or do you use a logging call with a message.

Jeremy: I think we need an identifier.

Scott: I tend to agree we should do that, even if we never do any sort of localization. It makes it easier to change that around when we need to.

Larissa: I think I would prefer to keep our options open.

Shane: I don't want it to be cumbersome.

Jeremy: I think we could put them all in one call.

Shane: So like defining the identifier as a string initially?

Jeremy: Maybe as a string with characters and digits, or maybe just numbers.

Michal: I would vote for characters and not just numbers, because then you can see what it means.

Jeremy: I think that's fine, but in the long run we'll have 400 different unique words. It could be cumbersome inventing them. Stephen: It's not. I put in a reference to the VMS manual.. it's just page after page of unique identifier. From a support point of view it's great.

Stephen: Going back to this making life awkward for developers. Realistically how difficult is it? You have to update 2 files.

Shane: I'm happy if it is easy, but like with the design of the unit test location, it needs to be kept in mind.

Shane: Conclusion:

  • We are committed to using an identifier-based system, regardless of whether we use localization.
  • We will ask users how much they care about localization.

BIND 10 team meeting

Proposed agenda

Jinmei: Some small things that were postponed to a face to face meeting. I don't remember each one of them.

Shane: I deliberately did not include certain topics because I wanted to make sure the most important topics were addressed. Perhaps I'll add a "topic backlog" so we can pick other topics.


Shane: I think this is all well-handled by e-mail. The only open topics I think are the dinner reservations and car rentals.

Meetings over the holidays

Missing some folks next week, but plan on normal Scrum planning sessions for the rest


Western Daily Call.

Jinmei: Since I was back to California I found it not working. I was told that in some of the days there would be no call due to the existence of another call. On other days I only saw Jeremy. Probably we will expect Scott after January. But I still think that it's not effective as it is supposed to be. So I guess we need to think about something different. We cannot expect any European developers, so maybe we need to change the time and invite some of the Asian developers. Another plan is to change the call and ask everyone to attend a single call on a "Best effort" basis. There may be other ideas. Maybe some of the US developer are only expected to attend the eastern calls when possible. It would still be much better than having the meaningless western calls in my opinion. The bottom line is: the western calls are currently not working.

Jeremy: We have a conflict with phone numbers. We need to decide on a phone numbers if we want to keep the same.

Larissa: I have a conflict on Thursdays and sometime on other days. I sometimes have conflicts, but I can make an effort to change that. I think it is mostly a quorum issue that might be different when Scott is around. I'm not opposed to changing the time, but I'm concerned that trying to get everyone on one call is tough. This time of day is difficult.

Scott: Also it's a bit unusual to have that sort of meeting in the middle of the day. I know that makes it difficult if you want to try to set up something with the eastern hemisphere. I think it would be more worthwhile if we had more people. I would expect these to take place at the beginning or the end of the day.

Jeremy: I think part of the problem in my case is that in the middle of the day we don't know what we're talking about. It seems a bit redundant and not useful. I'm not sure what the value is. Because we can't bounce ideas off of each other. Jinmei might be bouncing development issues that are not relevant to me and Larissa.

Larissa: It's not a gathering of the people working on the same type of project.

Jelte: The call itself is limited to telling what we did, but maybe our group is better for that. It's quite useful, because sometimes you really don't know what other people are doing.

Stephen: Sometimes you discover potential conflicts.

Jelte: Jinmei discovered this when he was in Japan.

Larissa: I'm not questioning the value of having a daily Scrum call. I know the eastern meeting is working well, and the BIND 9 scrum is working well, but it's not working good on the western Scrum.

Jinmei: Is it possible to make it team based? So first think about the R-Team, and then choose a best time for them. Then also for the A-Team.

Shane: That's possible. Let me make a couple of proposals via e-mail. We'll do this on the bind10-team list.

Jeremy: I wanted to mention I've been using the recursor at home for a couple of weeks now. My resolv.conf all point to it.

Shane takes a hint and ends the call.

Last modified 8 years ago Last modified on Dec 21, 2010, 3:55:34 PM