How can I change the help text that is shown when creating new cards? I d like to avoid the use of "new" vocabulary.
Also, how can I change the text, in the menu bar, for "My Card: Philipp"? I would like it to say something like "Hi, Philipp | My Account"
There are settings for "add help" and "edit help". Go to 'Options', which will give you the 'settings' for the card you are on. (On a User card, there are two tabs, this 'settings' and 'account' for permission and password, etc.) On most cards you go straight there on 'Options'.
Ethan has probably taught you a little about how you specify which cards get a setting.
The "Setting" is also a card, so you can go straight there, and see all the places that Setting is specified.
If all goes well this will link to those cards here at wagn.org:*add help *edit help
If I understand correctly, you're talking about the heading at the top of the page that says something like "New Industry Card", right?
Good news / bad news. The bad news is that there are still a few chunks of text that can't be reached by wagneering. You've mentioned two of them; another key area is the support text around account signups.
The good news is that as of 1.8, almost all of that text -- including the "New Whatever Card" header and the "*account links" text can be altered with simple modules. The one exception is the account stuff (for example the "Sign Up" header). That text is still caught up in special "Users" code, and the modules system only modifies Cards, so it can't yet be tweaked. As of 1.9, that will all be addressable in modules, too.
And by 2.0 (if not by 1.9 -- depends on funding), you will be able to change all of that stuff without having to use modules to do it. This work is tied in with internationalization priorities -- we obviously don't want hard-coded English anywhere. And I would say that the default setup should avoid any mention of the word "card" -- that's a wagneer's word, not a term for visitors / members.
--Ethan McCutchen.....Mon Apr 09 16:28:21 +0000 2012
So what's the takeaway? Let me know what you want these things to say and I'll write a module to take care of it or make it configurable.
--Ethan McCutchen.....Mon Apr 09 16:29:40 +0000 2012
Yeah, configurable would be great. Just a card, probably, a setting would be overkil? A "type trait"? MyType+*new header (you probably have a better idea for this) ? I guess if it has the Cardtype card as the context for inclusions, it could be a single card.
--Gerry Gleason.....Tue Apr 10 12:42:46 +0000 2012
Thanks both.
Indeed I meant the text "New ... Card", and then the text "Creating a new card is easy; you just need a unique name."
And configurable would of course be better, since whatever I say know might be outdated next week when I or someone else has a better idea :-) Plus I propably want to adjust the text depending on what type of card is created.
--Philipp.....Tue Apr 10 15:44:48 +0000 2012
Yeah, I guess there are a few more similar cases. Maybe we should put them behind a main card: Wagn Messages+new_type (+new_instructions, +new_missing (Oops ...) and so forth)? Also noticed some error messages that you may want to customize (Hitch in the Wagn ...)
--Gerry Gleason.....Tue Apr 10 17:30:08 +0000 2012
actually, you can override the "Creating a new card is easy..." text with an "*add help" or "*edit help" rule.
--Ethan McCutchen.....Tue Apr 10 18:24:49 +0000 2012
I didn't think so because I found it in the code, but not in cards.
--Gerry Gleason.....Tue Apr 10 19:39:11 +0000 2012
Ok, now I get it. You can override the text in the code with the *add_help setting.
Correct me if I'm wrong, but what you can't also do in the help setting is to have the logic that gives a different message when there is a broken_type or missing name, but you can override. Well, you still get the broken_type message regardless of the setting.
--Gerry Gleason.....Tue Apr 10 19:53:27 +0000 2012
Hmm, maybe we can do some special things with a few rules. FooType+*type+*add_help maybe should be used where it says "New FooType Card". Then maybe we should have one for the error case too (*broken_type as a setting?, that might lead towards *no_name, but then we are adding too many settings, I think) I think the use case is that we want to be able to have even more specific settings for exceptional conditions and fall back to a more basic setting when the specific ones are not present.
--Gerry Gleason.....Tue Apr 10 21:57:26 +0000 2012
I've got a proposal for this, actually. Was working on the design in the flight. It's considerably broader than just this issue.
In general, I want to work hard to avoid a proliferation of new settings -- that makes for confusing wagneering.
More soon...
--Ethan McCutchen.....Tue Apr 10 23:47:47 +0000 2012