You may want to test this just to be sure. We had a similar issue with translating board layer names in the old board file format which created a big headache when we implemented the current board file format.
On 5/23/2018 4:43 AM, Jeff Young wrote: > Reference/Value/Footprint/Datasheet are translated only in the UI: the > file always uses the English versions. (Presumably external tools will > look at the files, BOMs, netlists, etc.) > >> On 23 May 2018, at 00:41, Wayne Stambaugh <stambau...@gmail.com >> <mailto:stambau...@gmail.com>> wrote: >> >> 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 <j...@rokeby.ie >>> <mailto:j...@rokeby.ie> >>> <mailto:j...@rokeby.ie>> 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 <stambau...@gmail.com >>>> <mailto:stambau...@gmail.com> >>> <mailto:stambau...@gmail.com>> 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 : kicad-developers@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
