../../../../lib/lang/lang_str.c -> lang_str.thm.oIn file included from ../../../../lib/lang/lang_str.c:10:0:../../../../lib/lang/lang_str.h:957:2: error: #error The number of language string conditions does not match the number of language strings. Please update lib/lang/lang_str_conditions.h #error The number of language string conditions does not match the number of language strings. \ ^../../../makefile_sub.inc:26: recipe for target 'lang_str.thm.o' failedmake[1]: *** [lang_str.thm.o] Error 1makefile_base.inc:103: recipe for target 'all-recursive' failedmake: *** [all-recursive] Error 1

I'm not sure this is quite right yet. Adding new strings breaks. Or there needs to be a new procedure documented?

When adding new strings, lib/lang/lang_str_conditions.h also needs to be updated with the new string IDs. The #error message does include this detail, but it might be a bit obscure. I guess we could add a note to core/gui_lang.h as a reminder, if you think it's needed.

Quote

#error The number of language string conditions does not match the number of language strings. Please update lib/lang/lang_str_conditions.h

When adding new strings, lib/lang/lang_str_conditions.h also needs to be updated with the new string IDs. The #error message does include this detail, but it might be a bit obscure. I guess we could add a note to core/gui_lang.h as a reminder, if you think it's needed.

Thanks - that fixed it.

I'm not sure the best place to document this. Figuring out how to add a string and which files to modify has not exactly been obvious and we've just added another magic number file that needs to be updated.

For reference, I believe the new procedure for adding a string is :

Add the new string to ../CHDK/LANG/english.lng . Strings are numbered sequentially so try looking for an empty slot to insert the string. If you can't find one (or you are adding multiple strings that you would like to group together), add the string to the end of the file using the next free number(s).

Add any available language translations of the new string at the matching line in the ../CHDK/LANG/XXX.lng file. CHDK will default to the english text for the string if the associated translation does not exist in any language file.

Create a new entry in ../core/gui_lang.h that #defines a new label (uppercase by convention) that references the number(s) you created in step 1. Use this label in menus created in gui.c

Update the GUI_LANG_ITEMS value at the end of ../core/gui_lang.h if you added new entries.

Add a new blank entry to ../lib/lang/lang_str_conditions.h with the same location and number used in step 1

If the new string may not be needed on some cameras, add the #defined conditional name instead of "" in step 5

Not sure if this exists on the wikia ? I'll take a look and if I don't find it I'll look for somewhere appropriate to add it. Unless someone can point to where it already exists that is? Maybe this could also go into gui_lang.h as well?EDIT :update per philmoz comment below and an additional note about GUI_LANG_ITEMS.

When adding new strings, lib/lang/lang_str_conditions.h also needs to be updated with the new string IDs. The #error message does include this detail, but it might be a bit obscure. I guess we could add a note to core/gui_lang.h as a reminder, if you think it's needed.

Thanks - that fixed it.

I'm not sure the best place to document this. Figuring out how to add a string and which files to modify has not exactly been obvious and we've just added another magic number file that needs to be updated.

For reference, I believe the new procedure for adding a string is :

Add the new string at the end of ../CHDK/LANG/english.lng . Pick the next sequential number to start the inserted line.

Add any available translations of the new string at the end of the appropriate ../CHDK/LANG/XXX.lng file. CHDK will default to the english text for the string if the associated translation does not exist in any language file.

Create a new entry at the bottom of ../core/gui_lang.h that #defines a new label (uppercase by convention) that references the number you created in step 1. Use this label in menus created in gui.c

Add a new blank entry at the bottom of ../lib/lang/lang_str_conditions.h with the same number used in step 1

If the new string may not be needed on some cameras, add the #defined conditional name instead of "" in step 4

Not sure if this exists on the wikia ? I'll take a look and if I don't find it I'll look for somewhere appropriate to add it. Unless someone can point to where it already exists that is? Maybe this could also go into gui_lang.h as well?

Hmm, hadn't considered that aspect. It does seem a but cumbersome.

Perhaps an alternative solution might be to add the conditional as a comment to 'gui_lang.h' and then parse that file in makelang.c (instead of including lang_str_conditions.h).

I wan't criticising your implementation - it's a good addition.I hadn't thought through the implications to anyone wanting to add new strings - waterwingz description brought that into focus (no pun intended).

I have no problem with improvements (that also means it doesn't hurt my feelings if code written by me is replaced by something better).

In general, when I implement something, it can be expected that I go for an implementation that is easier for me to do.

Quote

Here's a patch that moves the conditionals to gui_lang.h - I think I've got them all (with the correct negative logic).Comments at the top of gui_lang.h should help anyone adding new strings.

Will take a look soon (but I guess this should generate the same gui_lang_default string as the code in trunk - if so, you could just check it in).

edit: the generated lang_str.h is indeed the same (minus the #error at its end), so I'm OK with this change

Seeing as we have gone this far, there is almost certainly a way to write a script to parse a single suitably formatted string input file that spits out the necessary .c and .h files ? Change the one input file, all the required output files change.

I guess the question it how much that is worth? srsa_4c's most recent patch is (maybe) not elegant but it works. I'm good with that unless a single unifying script is a fun project someone wants to do?