Wouldn't translating them defeat the purpose? I thought the goal was consistency. If you translate them, they will be different for each language and render code like kicost somewhat useless.
On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote: > Yes, the only way to make them translateable is to hard-code these and > other values into kicad, same as the existing hard-coded fields. > > That would be a good solution for me, having similar to layers a large > set of predefined fields, being able to name them and enable them at > will. But storing them in the files as the hard-codes values. > > This means a large change to the code though, at least if we must have > the enable/disable feature for this, along with creating new custom > fields. Not even the PCB editor has this yet. > > Also, I don't think any of the bom exporter plug-ins are localized, and > at least one of them completely ignores custom fields and adds it own > instead, regardless of what is in the file. > > Meanwhile my patch does not affect existing installations, does not > change any BOM, and does not enforce anything and comes in at a whooping > 3-4 lines of patch in a single file. It will however add 3 lines to two > dialogs (field editor and symbol editor) for new installations, which > can be removed, with 6 clicks of the mouse in eeschema. > > - Kristoffer > > On Tue, May 22, 2018, 20:01 Jeff Young <[email protected] > <mailto:[email protected]>> wrote: > > I can confirm that default fields only get added when the symbol is > edited AND the default field’s value is non-empty. So it doesn’t > seem to me that the proposed patch would pollute existing BOMs. Or > am I missing something? > > Seth’s comment regarding localisation is an issue, though, as we > don’t currently translate default fields. > > > On 22 May 2018, at 17:53, Wayne Stambaugh <[email protected] > <mailto:[email protected]>> wrote: > > > > On 5/22/2018 12:43 PM, Jeff Young wrote: > >>> It should output all fields defined in schematic symbols > regardless if > >>> each optional field is defined in every symbol. If they are > outputting > >>> anything other than that, I would consider this a bug. > >> > >> I had trouble parsing this. Are you saying that the list of > output fields should be the union of all fields which have a value > somewhere (but excluding default fields which are uniformly blank)? > > > > Yes. It should be the equivalent of a logical OR. If a field > exists in > > a single symbol, it should get added to the BOM. > > > >> > >> As it stands in 5.0, default fields don’t get pushed to symbols > unless the symbol is edited. At that point I’m not sure if they’re > all pushed, or only those with values. > >> > > > > It used to be that fields only get saved when they are added to the > > symbol using the edit symbol properties dialog. That code has > changed a > > lot since it was originally written so I cannot confirm this. > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
